브랜드의 번역

예전에 회사 팀장과의 에피소드:

팀장모씨: (팀원들에게) 리포트 쓸 때는 말이지 이건 저렇게 하고 저건 저렇게 하고..  그리고 전문용어 영어 단어같은 거 그냥 영어로 쓰라고. 다 알아들으니까 말이야.

창우: (속으로 투덜투덜...) 얼마나 다 영어로 쓰나요?

팀장모씨: 전부 다. 여기 단어 몇개 영어로 나온다고 문제 될거 없잖아? 오히려 엔지니어들한텐 그게 읽기 좋다고.

창우: 그거보다 훨씬 많아요. encoding, decoding, source code, compile, build, bug, editor, debugger, typing, ....  한글은 몇 개 안 남네요. (다 고쳐서 한 줄에 영어단어가 너덧개씩 있는 보고서를 보여준다) 자 이렇게 쓰면 가독성이 좋을까요?

팀장모씨: ...  (독해에 어려움을 겪는 모씨...)

썬의 번역 가이드

썬마이크로시스템에서 만든 StarSuite style guide에 보면 이런 말이 들어 있다.

1.4.2한국어로 번역하지 않는 용어들 (Do not translate)

1. 고유 명사나 소프트웨어, 운영 체제 등의 고유 이름

MySQL (ODBC) -
PostgreSQL
MySQL (JDBC)  
Mozilla
Adabas D      
Microsoft Outlook
Oracle JDBC   
Microsoft Windows
JDBC          
LDAP
ODBC          
Evolution
XStorable
...

이 부분은 내가 오픈오피스 번역 중에서 가장 못 마땅하게 생각하는 부분이다. 번역 가이드의 다른 부분은 몰라도 위 사항은 절대 따르지 않고 번역이나 음역하기를 권장한다. 특히 Gnome은 영문 그대로 쓰지 말고 "그놈"이라고 표기하기를...

Branding

"언어와 문화가 다른 지역에 진출할 때 기존 브랜드를 어떠한 형태로 사용할 것인가?", 이 문제는 어제 오늘의 문제는 아니다. 수십년동안 기업들의 글로벌화가 진행되면서 회사는 저마다 경우에 따라 다른 전략을 취해 왔고 뭐가 정답이라고는 쉽게 말할 수 없다. 보통 3가지 방법 중에 하나를 선택하게 될 것이다.

1. 본래 브랜딩의 철자를 그대로 가져간다.
2. 본래 브랜딩을 그 나라의 언어에 맞게 음역한다.
3. 본래 브랜딩을 포기한다. 새로운 브랜드를 만들어 낸다.
   

실제로 한국에 진출한 글로벌 기업은 어떤 전략을 사용했을까?

영어 약자로 된 브랜드는 (KFC, HP, ...) 음역으로 쓸 수 없기 때문에 다른 선택이 없지만, 그 외에 1의 선택을 하는 경우는 의외로 별로 많지 않다. 길거리에서 영어로 가득한 간판을 보긴 하지만, "우리 STARBUCKS는..."이라고 회사 소개를 하지는 않는다. 거의 모든 회사가 "맥도나알드~"라고 멋드러지게 한글 음역을 이용하지 TV 화면을 영어로 가득 채우지는 않는다.  우리들도 일상 생활에서 "아웃백에서 봐요"라고 문자를 보내지 "Outback에서 봐요"라고 쓰지는 않는다. (게다가 1바이트 더 많다!)

3번째로 새로운 브랜드를 만들어 내는 경우도 잘 찾아보면 드물지 않게 볼 수 있다. 햄버거 체인점인 하디스(Hardees)는 미국의 찰스 쥬니어를 가져온 것인데 찰스 쥬니어는 말도 길어지고 왠지 맛있는 느낌이 안 나니까한국판에서는 새로운 말을 만들어 냈다. 한솥도시락은 일본의 도시락 체인점인 혼께가마도야의 메뉴와 시스템과 인테리어를 그대로 가져왔지만 이름은 우리말로 다시 지었다.

1과 2의 장단점을 적당히 취하는 경우도 볼 수 있다. 많이 사용하는 방법이 로고는 원래 영어가 들어간 로고를 무슨 그림 마냥 그대로 사용하면서 글자로 쓸 경우는 한글 음역을 사용하는 방법이다. (스타벅스, 커피빈, 아웃백 스테이크하우스, 리바이스, ...)  원래 로고와 한글 로고를 둘 다 만들어 놓거나 원래 로고의 영어에 한글 표기를 추가하는 식으로 동시에 사용하면서 글자로 표기할 때는 한글 음역을 쓰는 경우도 있다. (맥도날드, 버거킹, 철수하기 전의 월마트, ...)

하지만 로고나 간판을 원래 브랜드 그대로 이용하는 경우는 많아도, 일반 광고나 보도자료 등의 일반 텍스트 문서에서 영어 표기를 고집한 회사는 한국에 들어온 글로벌 기업중에 거의 없었다. (약자로 된 브랜드는 제외.) 몇가지 예외가 있으니 바로 소프트웨어 회사들이다. 마이크로소프트는 양지사 와의 상표 분쟁에서 패소했기 때문인지는 몰라도 "Windows 95" 이후 계속해서 한글마이크로소프트의 제품 설명에서도 "Microsoft Windows" 영문 표기를 고집하고 (그 전에는 "윈도우"라고 사용했다) 오피스의 경우에도 프로그램 메뉴에까지 "Microsoft Word"라고 영문으로 들어가 있다. 어도비, 오라클 등등 모두 영문 표기를 고집하고 있다. (하지만 광고나 그렇지 절대로 언론은 영문 표기로 보도해 주지 않는다.)

한글로 음역해서 쓰는 이유는 그게 세종대왕과 주시경선생께서 기뻐하시는 옳은 방향이라서가 아니라, 그게 더 올바른 브랜딩 전략이기 때문이다. 잠재적인 소비자들에게 쉽게 인식되고, 쉽게 기억되고, 눈에 잘 뜨이는 게 좋은 브랜드이다. 현재 평균적인 한국 소비자들은 왠만큼 교육 수준이 높은 경우에도, 영어 그대로 쓴 브랜드는 기억하거나 인식하기에 힘든 게 현실이다. 물론 본래 브랜드를 지역화하는 비용도 있고 본래 브랜드가 손상될 우려가 있어서 본래 로고를 남겨두고 일부만 지역화한다든지 선택을 할 수는 있다. 하지만 트레이드오프로 그런 선택을 할 수는 있어도 영어로 쓰는 게 한글로 쓰는 것보다 더 원래 의미를 전달하니까 좋은 브랜딩이다라고는 할 수 없다.  구찌, 버버리, 까르티에의 영문 철자를 기억하고 있는 사람이 얼마나 될까?  (소프트웨어 회사들이 예외적인 전략을 쓰는 이유는 한국의 소프트웨어 소비자들이 영어에 익숙하기 때문일까?)

에볼루션은 있는데 Evolution은 어딨지

썬의 번역 가이드는 첫째로 한국에 진출한 브랜드들이 취한 현실과 다르다. 위에서 말한 것처럼 한국에 진출한 글로벌 기업의 대부분은 브랜드를 한글로 음역했다. 특히 그놈 에볼루션은 분명히 (내가!) 한글로 "에볼루션"이라고 음역했고 한국어 데스크탑에는 프로그램 정보 창을 보지 않는 한, Evolution이라는 단어도 찾아보기 힘든데 예제에까지 "Evolution"이라고 써 놓는 건 맞지 않다.

또 (소프트웨어 회사들의 상업용 소프트웨어들도 그렇지만) 그 지역의 언어로 표기하는 편이 쉽게 인지되고 기억되는 더 좋은 브랜딩인데도, 왜 OpenOffice.org, Firefox 따위의 번역도 그 "OpenOffice.org", "Firefox"라는 이름만은 영문 표기를 하는 브랜딩을 고집하는지 이해하기 힘들다. (번역자 맘대로 건드리기도 힘들게 만들어 놨다.)

번역 메세지에서 남용되고 있는 말

기반  (based on, derived)

위하여 (to ~, for ~)

~하는 것이 (to ~, what/which/that ~)

적절한/적절히 (proper, appropriate, accordingly, ...)

제공 (provide, offer, come with, ...)

설정 (option, configure, preference, property, ...)

포함 (have, contain, exclude, consist of, ...)


"A를 기반으로 하는 적절한 B를 포함하기 위해 C 설정하는 것을 제공합니다"

위의 단어를 합쳐보면 이 정도 문장이 되는데...  의외로 많은 메세지 번역에서 제공하고 설정하고 포함하는 정도로 상당히 수많은 영어 단어를 번역하고 있다. 형태소 분리 프로그램이 제대로 돌아가는 게 있다면 PO 파일의 단어들에 대해 통계를 내는 것도 의미가 있어 보이는데..  나를 포함해 누가 한 번역도 이 빈약한 번역 어휘의 문제에서 자유롭지 못할 것이다.

해결 방법은 평소에 폭넓은 독서와 글쓰기를...  (논술 시험?)

GtkBuilder 탐험

GTK+ 2.12에 포함된 GtkBuilder 기능에 대해 탐험해 보면,

GtkBuilder는 libglade의 대체품이라고 말할 수 있다. GUI의 구성을 코드 내에서 하지 않고 XML 파일로 기술하고 런타임에 그 XML을 읽어들여서 UI를 구성한다. libglade를 써 봤다면 별로 새로운 건 아니겠지만, 일단 GTK+에 포함되어 버렸으니까 추가로 libglade를 링크할 필요가 없다는 장점이 있다. 또 일부 glade가 커버하지 못하고 있는 TreeView 따위의 복잡한 위젯도 쓸 수 있다. 요즘에 하드코딩으로 GTK+ 코딩하는 사람들이 거의 없다는 걸 생각해 보면 충분히 GTK+에 포함될 만한 기능이다. (GTK+가 너무 커진다 싶으면 언젠가 메이저 버전 뒤엎겠지.)

간단히 맛보기 필요한 소프트웨어: GTK+ 2.12 이상, pygtk (컴파일이 귀찮으므로)

import gtk
builder = gtk.Builder()
xml = '''
<interface>
  <object class="GtkWindow" id="cwwindow">
    <child>
      <object class="GtkButton" id="cwbutton">
        <property name="label">Build Me</property>
      </object>
    </child>
  </object>
</interface>
'''
builder.add_from_string(xml, len(xml))
win = builder.get_object('cwwindow')
win.show_all()
gtk.main()

위 파이썬 코드를 실행하면 이런 창이 나온다.

libglade를 사용해 봤다면 XML 문법만 다르지 별 다른 점을 느끼지 못할 것이다. 또 대부분의 glade 파일은 gtk 2.12에 포함되어 있는 gtk-builder-convert 프로그램을 이용해 GtkBuilder용 XML 파일로 변환할 수 있다. ui.glade라는 파일로 저장을 했다고 하면,

$ /usr/bin/gtk-builder-convert ui.glade ui.xml
$ python
Python 2.4.4 (#2, Aug 16 2007, 02:03:40)
[GCC 4.1.3 20070812 (prerelease) (Debian 4.1.2-15)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import gtk
>>> builder = gtk.Builder()
>>> builder.add_from_file('ui.xml')
>>> builder.get_object('window1').show_all()
>>> gtk.main()

GtkBuilder의 장점은 "눈에 보이지 않는 오브젝트"를 정의할 떄 나온다. 특히 libglade를 사용할 때는 UI 디자인에서 지정하지 못하고 코딩으로 해결해야 했던 복잡한 위젯, 특히 모델/뷰/컨트롤러 개념이 필요한 TreeView, ComboBox 따위의 "모델"을 XML 파일에 집어 넣을 수 있다. 이 부분때문에 디자인과 프로그램이 완전히 분리하지 못했던 많은 코드를 분리할 수 있다.

<interface>
  <object class="GtkListStore" id="treemodel">
    <columns>
      <column type="gchararray"/>
      <column type="gint"/>
    </columns>
    <data>
      <row>
        <col id="0">cwryu</col>
        <col id="1">2</col>
      </row>
      <row>
        <col id="0">crew</col>
        <col id="1">1</col>
      </row>
      <row>
        <col id="0">clue</col>
        <col id="1">3</col>
      </row>
      <row>
        <col id="0">None of the Above</col>
        <col id="1">4</col>
      </row>
    </data>
  </object>
  <object class="GtkWindow" id="window1">
    <child>
      <object class="GtkTreeView" id="cwbutton">
        <property name="model">treemodel</property>
        <child>
          <object class="GtkTreeViewColumn" id="column0">
            <property name="title">Name</property>
            <child>
              <object class="GtkCellRendererText" id="r0"/>
          <attributes>
        <attribute name="text">0</attribute>
          </attributes>
        </child>
      </object>
    </child>
    <child>
          <object class="GtkTreeViewColumn" id="column1">
            <property name="title">Number</property>
            <child>
              <object class="GtkCellRendererText" id="r1"/>
          <attributes>
        <attribute name="text">1</attribute>
          </attributes>
        </child>
      </object>
        </child>
      </object>
    </child>
  </object>
</interface>

위의 XML 파일을 마찬가지의 python 코드로 돌리면,

이렇게 스트링-숫자 형식의 "모델"과 cwryu/crew/... 따위의 데이터를 포함할 수 있다.

현재 그놈 프로그램은 거의 glade만을 사용하고 있다. 내년 3월이나 9월 릴리스에서 libglade에서 옮겨올 수 있을까? 많은 사람들이 어려움을 호소하는 걸 보면, 얼핏 보면 깔끔하고 좋아 보이지만 실제 적용하기는 쉽지 않은 모양이다.

아시나요 - 데비안 미러

ftp.debian.org 망가진 기념으로 잘 알려지지 않은 진실을 써 보면:

• 데비안 메인 사이트 ftp.debian.org -- 아니다. 이 사이트는 데비안 메인 사이트가 아니라 1차 미러의 하나일 뿐이다. 마스터 사이트는 외부에서 접근이 불가능하다.
  
• 그래도 ftp.debian.org가 제일 안정적이다 -- 아니다. 지금 하드 공간이 모자라서 업데이트가 안 되는 상태이고, 다른 1차 미러들은 멀쩡하다.
  

하지만 ftp.kr.debian.org는...  몇 개 사이트로 분산시키는 게 좋지 않을까? 카이스트 네트워크가 시도때도 없이 변화한다는 건 익히 알고 있는 사실이지만 "주5일제"라는 말을 할 정도로 너무 불안하다..  기업의 ftp 미러가 지속적으로 미러해 준다는 약속을 해 준다면 모르겠는데, 과거의 다른 기업 사이트들은 하드 모자라기만 하면 데비안을 지워버렸기 때문에 믿기도 난감하다.. -_-

데비안 문제 (4) - 프로젝트 인프라

데비안 문제 (1) - unstable
데비안 문제 (2) - 새 패키지 큐와 FTP 마스터
데비안 문제 (3) - 메인테이너와 패키지에 대한 권한 에 이어,

데비안 프로젝트 문제에 대해서는 새로 쓸 얘기가 없었지만, 마침 지금 문제가 되고 있는 프로젝트 인프라에 대한 이야기를 적어본다.

데비안 프로젝트에 참여하면, (상당수의 자유소프트웨어 프로젝트와는 달리) 프로그램과 절차의 대부분이 문서화되어 있다는 데 놀란다. 그리고 constitution(헌법?)부터 시작해서 투표를 통한 선거와 general resolution (국민투표?) 등 의사 결정 과정까지도 정리되어 있다는 데 또 다시 놀라게 된다. 그런데 의외로 프로젝트 인프라의 몇몇 부분은 implicit하게 몇몇 사람의 주도로 돌아가는 부분이 있다. 수년간 여기에 대한 불만이 있었고 결국 칼을 쥔 리더한테서 다음 메일과 같은 불만이 터져 나왔다.

Making Debian work: a question of trust indeed

이상하게 몇몇 인프라는 제임스 트룹 한명에게 집중되어 있다. 데비안 개발자가 될 수 있냐 여부의 핵심적인 권한인 데비안 키링, 계정 생성 따위의 업무 말이다. 이러한 업무가 배후 세력의 음모에 따라 돌아간다는 얘기는 아니다. 이 메일에서 지적하고 있는 건 제임스의 아무 이유 없이 일을 늦게 처리하면서도 자기 일거리를 넘기지 않아서 (다른 사람을 못 믿어서?) 생기는 문제이니까. new maintainer 프로세스를 빠르게 돌아가도록 정비한 게 상당히 오래되었음에도 불구하고 수년간 계정 생성과 키링 문제에서 병목 현상을 일으킨 장본인이다.

적어도 constitution에 따르면 리더가 결단을 내리면 이 상황을 바로잡을 수 있다. 하지만 결단을 내린다고 해도, 프로젝트의 시작과 같이한 이 이상한 인프라 체계가 쉽게 바뀔 수 있을지는 모르겠다.

(그렇다고 해서 현재 데비안의 인프라 운영이 특별히 비민주적이다라거나 몇명의 결정에 의해 돌아가는 나쁜 모양이라고 생각하지는 않는다. 데비안이 아닌 다른 프로젝트는 인프라 전체가 한명이나 특정 회사 스폰서쉽에 지배되서 돌아가는 일이 허다하니까.)

버전 컨트롤 시스템 황당

버전 컨트롤 명령어를 사용하면서 이해가 힘들었던 몇가지,

• 왜 cvs merge는 merge하지 않는 걸까?
• 왜 svn move는 move하지 않는 걸까?
• 왜 git revert는 revert하지 않는 걸까?

merge는 또 다른 modify로 기록될 뿐이며, move는 delete와 add로 기록될 뿐이다.

cvs/subversion에 익숙해 지고 나서 착각하기 쉽지만 git revert는 로컬 변경사항을 버리는 명령이 아니다.  명령어부터 시작해서 지난 버전컨트롤 프로그램들의 관례를 무시한 git, 알아갈 수록 당황스럽다.

glibc 2.7

당장 눈에 보이는 건 이 정도.

리눅스 커널 2.4 지원 중단
- 과거에 80386에 대한 지원 중단이라든지, 마이너 아키텍쳐에 대한 사실상의 지원 중단, 몇몇 아키텍쳐에서 바이너리 호환성 깨는 등등 호환성 문제에서 바람잘날 없던 glibc가 이번엔 커널 2.4에 대한 지원을 중단했다.

번역 보충
- 게으른 glibc 메인테이너 덕분에, (그리고 제대로 안정된 릴리즈가 없었던 까닭에) Translation Project에 몇년간 번역문을 요청하지 않고 있다가 최근에야 새로 번역문을 업데이트했다.

OSS 정책 - "ETRI `큐플러스' 의료 장비에 탑재"

ETRI `큐플러스' 의료 장비에 탑재 (2007/11/14)

큐플러스의 정체는 임베디드리눅스 개발 키트이다. 몬타비스타라던가 임베디드 리눅스 개발지원을 하는 수많은 기업들이 이미 이런 툴을 제공하고 있다. 꽤 오래된 물건이고  SF.NET 페이지에서 초기 버전을 받을 수도 있다. (지금은 관리하지 않는 것 같지만) 크로스 빌드용 컴파일러 툴체인, 라이브러리, 커널 등등을 모아 놓은 것으로 그 이후 버전은 모르지만 내가 받아봤던 2002년 경 초기 버전은 iPAQ에 호환되게 만들었다.

이 오래된 물건에 대해 새삼스럽게 조사하느라 수고하기도 귀찮고, 그럴 필요도 별로 없어서 대충 기억들을 열거해 보면...

• ETRI의 프로그램을 따라가자면 상당한 액수의, 그것도 런타임 로열티를 지급해야 했다. 그게 QPlus에 대해 사람들이 시큰둥한 가장 큰 원인이었다. 외산소프트웨어 대체가 목적이었다면 좀 싸야 하지 않았을까?
  
• 다른 판매된/공개된 ready-made 개발키트나, DIY에 비해 별로 특이한 사항도 없었고 말이다. 이 오래된 녀석이 5년이 지난 지금에서 다시 뉴스에 등장할 줄은 꿈에도 몰랐다. (보도에는 2005년 개발이라고 되어 있는데 어찌된 일인지?)
  
• "그동안 정보가전 솔루션, 텔레매틱스 솔루션, 스마트폰 등 모바일 단말 솔루션 등에 사용돼 왔으며"라고 되어 있지만, 믿기 힘들다. 어설프게 진입하려고 하다가 로열티만 낭비했던 기업이라면 몰라도...
  
• 그것보다도 옛날에 관계자들을 만났을 때, 내가 셋탑 만든다니까 마치 QPlus가 표준이니까 다 써야 한다는 듯이 주장하던 사람들의 얼굴이 떠올라서...

OLPC 배포국가

OLPC 배포국가: 브라질(포르투갈어),멕시코(스페인어),우루과이(스페인어),페루(스페인어),팔레스타인(아랍어),리비아(아랍어),나이지리아(아프리칸/영어),에티오피아(암하라),르완다(르완다어/프랑스어),타이(태국어).. 

OLPC를 쓰고 싶은 개도국 어린이는 영어부터 배워야?

괜한 네거티브가 아니라..  OLPC 하드웨어는 양산을 시작했지만, 소프트웨어 완성도는 아직 "글쎄"다. 국제화나 번역쪽은 특히나 진행이 느려서 사실상 영어 못 쓰면 사용이 어렵다. 네그로폰테가 방한해서 잠깐 했던 말처럼 북한에 OLPC를 보내는 사업을 하게 된다면, 한국어 XO 번역 커뮤니티를 만들 필요도 있을 것이다.

(업데이트) 지금 OLPC 한국어 개발과 관련되어 참여하고 있는 "것처럼 보이는" 사람들은, 방향이 현실성 없는 정치적인 활동이나 OLPC의 기본 방향과 다르게 별개 사업을 진행하려고 하고 있다. 이 사람(들)이 지금 활동하고 있는 것 같지도 않고 이대로 성공할 거라고 생각하지도 않지만, 혹시라도 이러한 방향으로 협조하지는 말기를..

OSS 정책 - 부요, 그 이름과 방향

저번 부요에 관한 네거티브이야기에 이어서, 가십성이긴 하지만 부요의 이름과 그 정의에 대해 생각해 보면,

2004년인가, 2005년에 부요 프로젝트에 몇단계에 건너서 관여된 누군가와 대화를 했었다.

창우: "어, 영어로 Booyo인데 부요 아니었어요?"
누군가: "부여예요"

드라마 "주몽"이 살던, 대소왕자가 살던 그 부여! 오래전 쓰여진 KLDP 위키 페이지에도 그 흔적이 일부 남아 있다.

• BONE:사업 코드명이며 공개SW (OSS: Open Source Software, 뼈)의 本, 골격을 의미
• BOOYO:결과물코드명이며 중국 중원의 대부여의 맥, 일본의 근간인 백제(부여의 계승)의 맥으로써 리눅스 제국 건설을 의미함

너무 민족주의 코드가 들어있었기 때문이었을까? 아니면 다른 어떤 사연이 있었는지 결국 이름은 "부요"가 되었다. KDE가 맨 처음 announcement에서는 "Kool Desktop Project"였는데도 시간이 갈 수록 잊혀져서 "K Desktop Project"가 되었듯이, 부요라고 바뀐 이름은 새로운 의미로 해석되었다. 그런데 이상하게도 영문 위키피디어 페이지에만 부요의 설명이 상세하게 되어 있고 한글 페이지에는 별로 언급이 없다. 이름에 대한 설명을 보면,

Booyo is a Korean onomatopoeia yelled at during pheasant hunting to make the birds take wing, hence meaning the new soaring of the Linux platform in Korea. The Booyo logo shows a penguin taking off the ground. A homonym of Booyo means being rich.

"being rich"...  "부자 되세요?"  한글로 된 설명도 KLDP 게시판의 일부 댓글에서 찾을 수 있다.

    정식 한글 명칭은 '부요' 입니다. '부요'는 표준 스펙으로서의 기능도 하고 해당 스펙을 준수하는 배포판 기능도 합니다.

    이름의 유래는 남쪽지방의 꿩잡기 할 때 나는 소리입니다. 꿩을 잡을때 몰이꾼이 내는 소리가 부요... 뿌요.. 뭐 그렇다고 하는데 인턴인 제가 봐도 믿거나 말거나입니다. :)

어쨌거나, 이름이 그렇게 변화되어 왔는데...  부요의 이름이 바뀌면서 처음에 구상했던 BONE/BOOYO의 구분이 애매해 진 것일까?  부요가 표준인지 배포판 제품인지 명확하지가 않다. 부요를 단순히 "부요 표준을 준수해 구현된 제품"이라고 정의하기에는 사람들이 하는 말이 앞뒤가 맞지 않다. TTA에 표준으로 공개된 수준의 부요 표준은 매우 대략적이고 선언적인 기준만 제시되어 있기 때문에 사실상 거의 모든 리눅스 배포판이 부요 compatible이라고 주장할 수도 있을 정도인데, 사람들은 부요의 제품성에 대해서 말하고 있다.

몇 가지 예를 들어 보면,

• 부요는 LSB 3.1 certification을 받았다. 그러면 부요는 배포판 제품인가?  (참고로 LSB는 Linux Foundation에 인증을 신청하면 제출하는 제품을 기준으로 certification을 부여한다. 부요가 LSB certification을 받았다고, 부요 인증만 하면 LSB 인증이 자동으로 되는 거 절대로 아니다.)
• 부요는 TTAS.KO-05.0037 및 TTAS.KO-05.0038로 한국정보통신기술협회(TTA)의 표준으로 등록되어 있다. 그러면 부요는 표준인가?
• 부요는 ETRI와 리눅스 배포판 업체들과의 합작품이다. 그러면 부요는 제품인가?
• 2005년 12월, TTA로부터 프로젝트 그룹의 표준화 활동 공로로 ETRI 연구원들이 표준화 공로상을 수상한바 있다. 그러면 부요는 표준인가?
• 제품 성능에 대해 말하고 있는 부요 관련 신문 기사들을 보면 역시 부요는 제품인가?  ("부요 프로젝트는 돈먹는 하마?",   "리눅스 플랫폼, 부요 기반 배포판 무상보급 신경전")

부요 리눅스를 서치해 봐도, 리눅스 이용자들은 부요를 리눅스 배포판 제품으로 생각하고 말한다. 업체들은 물론이고, 정부 관계자들도 부요에 대해 선전할 때도 화려한 각종 기능을 선전하는 걸 보면, 부요 표준이 아닌 부요 배포판에 대해서 말하고 있다. 하지만 정책 입안자들과 ETRI에서는 부요를 표준 플랫폼이라고 말하고 있다. 그런데 또 표준 문서만 준수한다고 부요 인증을 해 주는 것도 아니다.

무엇이 맞는 얘기일까? 정책의 애초의 목적, 진흥원, ETRI, 업체, 사용자가 모두 다른 방향을 바라보고 있는 게 아닐까?


(나중에 귀차니즘이 회복되면 부요의 다른 부분에 대해서 계속)

OSS 정책 - "리눅스OS `부요 2.5` 기술이전"

리눅스OS `부요 2.5` 기술이전

ETRI 공개SW솔루션연구팀 우영춘 팀장은 "부요는 그동안 수 차례의 기술이전을 통해 국내 공개SW 활성화에 매우 긍정적인 영향을 미쳤다고 본다"며 "이번에 기술이 이전되는 부요 2.5 버전은 데스크톱 SW 플랫폼의 경우 업데이트 기능이 대폭 강화됐고, 서버 SW 플랫폼은 최근 업계의 이슈가 되고 있는 가상화 기능이 포함된 것이 특징"이라고 말했다.

여유가 되면 부요 프로젝트의 문제에 대해 모두 써보겠지만...  (한국형 규격이라는 어긋된 방향, 정부기관 주도의 커뮤니티가 없는 폐쇄적 진행 등등)  그 중에서도 한 가지 문제가 지금 당사자들이 하고 있는 자화자찬식 정책 평가의 문제이다. 생색내기와 과장된 보도자료는 부요 관련뿐만 아니라 모든 정부산하기관의 문제이기도 하지만, 부요가 대체 어떤 긍정적인 영향을 미쳤다는 건지 이해하기 어렵다. 현재 상황은 오직 부요를 만든 당사자들만 부요에 대해 말하고 있는 실정이다.

부요 규격이 하는 일이 레드햇/수세/우분투의 최신 기능과 (업데이트/가상화) 최신 버전을 써 넣는 것일까?  실제 현재까지 표준화된 규격을 보면 부요 규격은 리눅스 커널 옵션, LSB/FHS, 그리고 Fedora 최신판을 설명한 것에 지나지 않는다.

레드햇-노벨, 특허 침해로 피소?

레드햇-노벨, 특허 침해로 리눅스 벤더 중 최초로 피소

IP innovation이 애플을 고소했던 것과 동일한 특허로 레드햇과 노벨을 고소했다고 한다. 그 특허의 내용은 다음과 같다:

"workspaces provided by an object-based user interface that appear to share windows and other display objects."

ROTFL...

이 쉬운 단어들로 이렇게 애매하게 조합을 해 놓으면, 아마도 윈도우 시스템을 갖춘 모든 종류의 GUI가 여기에 해당할 것이다.

특허 제도의 폐해를 가장 잘 드러내 주는 대표적인 예가 바로 IP innovation과 같은 기업이다. 이러한 지적재산권 소송 전문 기업은 소프트웨어뿐만 아니라 모든 분야마다 존재한다. 그 분야에 실제로 연구개발이나 상품화를 진행하지는 않고, 오로지 지적재산권 거래와 소송을 통해 회사가 유지된다. 여러가지 이용 가능성이 높다고 생각되는 특허들을 사들여서 보유한 다음, 돈이 많다고 생각되는 기업들을 상대로 협상과 소송을 통해 매출을 올린다. 이러한 회사들은 실제로 소송의 최종 판결에서 승리할 가능성이 없더라도, 대기업을 상대로 위협을 가하면서 적당한 가격을 협상해 실질적인 수익을 올린다. (큰 기업 입장에서는 오랜 소송끝에 얻은 승리보다는 돈을 주고 협상하는 편이 더 이득일 수가 있으니까.)

그런데 노벨은 어쩔까? 특허를 전면에서 부정하기에는 찔리는 게 많을 텐데..

메일링 리스트와 Reply-To 헤더

(gnome-kr 메일링 리스트에 쓴 메일에 나오는 이슈를 재구성)

다른 분야라고 크게 다르지 않지만 컴퓨터 분야에서 수십년동안 계속되어 온 플레임^H^H^H토론들의 공통점은

• 많은 사람들이 자주 접하는 주제이다.
  
• 많은 사람들이 쉽게 이해할 수 있는 주제이다.
• 둘 다 상당한 숫자의 사용자/지지자가 있으며 살아생전에 사라질 것 같지 않다.
  
• 결국 똑같은 갑론을박만 하게 된다.

Emacs와 VI, C++과 plain C, 코딩 스타일, micro kernel과 monolithic kernel, CISC와 RISC, little endian과 big endian, ...   아마 게시판에 이중에 한 가지 주제를 장난처럼 한마디 쓰면 수많은 사람들이 전문가라도 되는 듯이 리플이 주루룩 달릴 것이다. 하지만 그 리플의 내용도 수십년전과 다르지 않다..

메일링 리스트가 발송하는 메일에 Reply-To 헤더를 붙이는 게 좋은가도 논란의 여지가 있고, 이야기를 하면 결국 똑같은 주장과 똑같은 반론이 나올 수밖에 없다.  일단 내가 읽고 있는 debian/gnome/fd.org/... 메일링 리스트들은 모두 Reply-To를 추가로 안 붙이는 정책을 쓰고 있고 거기에 동의하고 있다.  하지만, 여전히 반론도 읽어 볼 만한 가치가 있으므로~

Reply-To 반대 의견: http://www.unicom.com/pw/reply-to-harmful.html
Reply-To 찬성 의견: http://marc.merlins.org/netrants/reply-to-useful.html

CRM 스팸

요즘 스패머들의 경쟁상대는 바로 같은 스패머들. 어떻게든 읽게 하려고 별 짓을 다 하는데...  아무리 제목을 스팸처럼 안 보이도록 창의성이 떨어지고 스패머들이 서로 이용하기 때문에 나중에는 다 스팸처럼 보이게 된다. 그래서인지 오늘 받은 스팸은 아예 slashdot 제목을 활용하기 시작했다.

보낸 사람: sdalton 받는 사람: cwryu 제목: Survey Says GPLv3 Is Shunned 날짜: Wed, 26 Sep 2007 15:36:21 +0200 (22:36 KST)

CHINA VOICE HOLDING
Hot Stock in Momentum play for the week

OTC : C,HV~C
This company is nasdaq bound

...

그래도 slashdot의 꽤 최근 기사임. 자동화한 걸까?

Being Evil - 기사 링크 눌렀을 때 그 기사의 카테고리 띄우기

어제 오늘의 이야기도 아니고 포털의 운영 전략은 언제나 정보를 집중시키는 것이었다. 유저가 떠나가지 않고 계속 이용하게 만드는 것. 그래서 상단에 포털의 각종 기능을 이용할 수 있는 링크를 포함하고, 포털의 본 컨텍스트에서 벗어나려고 할 때 새 창을 띄우는 식으로 벗어나지 않게 만들고, 어떤 페이지에 들어갔을 때 연관된 페이지를 보여준다던가 하는 식의 기법을 도입했다.

하지만 상식적으로 각 사이트의 대문에서 기사 링크를 눌렀을 때 이용자의 의도는 그 기사를 보는 것인데, 그 기사가 안 뜨고 그 카테고리가 뜬다는 건 뭔가 이상하다. 원클릭을 투클릭으로 2배 비효율적으로 만들어 버렸다. 그렇게 해서 포털이 얻은 것과 잃은 것은 무엇일까?

(버그때문인 것 같은데..  다음의 경우 기사 링크를 눌렀을 때 그 기사가 카테고리 상단에 안 나올 때도 있다. 그러면 그냥 뒤로 가기 단추 눌러 버린다...)

iceweasel을 iceweasel이라 부르지 못하고...

한메일Express라는 것에 당첨되었다...라고 하는 메일이 한메일에 쌓였길래, 보려고 했더니 왠일인지 똑같다. 뭔가 이상해서 환경설정에서 Express 사용여부를 설정하면서 자세히 관찰해 보니까 뭔가 다른 페이지를 들어가려고 하다가 나가는 현상이 보였다. 그 순간에 나왔다 사라지는 한마디, "IE, Firefox 1.5, ... 이상에서만 사용할 수 있습니다."

"지금 iceweasel 무시하나요?"를 머리속에 대뇌이면서 about:config 에서 user-agent 값을 firefox로 고쳐버렸다. 그러니까 무리 없이 한메일Express로 잘 전환되었다.

그런데 머리 속을 스치고 지나가는 생각. "지금까지 티스토리의 에디터가 epiphany에서만 동작하고 iceweasel에서 동작하지 않은 원인이 설마 이것일까?" 지체없이 티스토리로 로그인, 에디터를 써 본 결과 맞았다. 얄밉게 잘 동작하는 에디터...  (epiphany에서도 찾아보니까 예전에 user-agent를 고친 설정이 남아 있었다.) 한메일은 그렇다 쳐도, 태터툴즈 에디터가 user-agent를 보고 다르게 동작할 줄은 꿈에도 몰랐다.


PS. "어쩔 수가 없이 이렇게 만들었다"라고 하기엔 iceweasel이라는 user-agent로 잘 동작한 웹용 에디터들이 너무 많다.

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

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

예를 들어 좀 구버전의 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는 시대를 잘못 타고났다?)

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를 쓸 필요까지야 없겠지만 백엔드의 한계때문에 변경 사항의 기록을 남기도록 고치는 것도 매우 힘들다.

Linux x86 64 환경

데스크탑을 core2duo로 업그레이드하면서 64비트 리눅스의 세계로 빠져들었다.

사실 현재 시점에서는 64비트 데스크탑 OS는 별 메리트가 없다.  좀 더 시간이 지나서 대용량 홈 비디오 편집이라던가 그런게 일반화되거나, 엄청난 양의 데이터를 메모리에 갖고 있어야 하는 컴퓨터 게임이 나오거나 해야 상황이 달라지려나?  요즘의 기껏해야 전체 메모리가 수 GB 내외인 데다가 애플리케이션도 GB 단위의 메모리를 사용하는 애플리케이션이 없는 현재 상황에서는 메리트가 없다.

어쨌든...  새로운 세계의 도전을 핑계삼아 최근에 시도한 바로는 몇가지 걸림돌이 있었다.  문제는 과거의 ia32 바이너리들이다.

vmplayer - 의외로 그냥 까니까 동작했다.  호환 라이브러리만 (데비안/우분투의 경우 ia32-libs 및 ia32-libs-gtk) 잘 설치해서 쓰면 문제가 없다.  단 imhangul을 쓰고 있다면 imhangul도 GTK+ 호환성 라이브러리에 맞게 깔아야 해서 xim/nabi로 쓰는 게 속편하다.

enemy territory - 왜 nvidia glx가 호환성 라이브러리가 (nvidia-glx-ia32) 있는지 생각하다가 테스트해 보려고 설치해 본 것.  역시 설치하니까 아주 잘 된다.  (왠지 옛날보다 많이 죽는 느낌이 드는 것 같은데 -_-)

flash - 첫 번째 걸림돌.  standalone program이 아니라 다른 프로그램의 플러그인이기 때문에 골치가 아프다.   Adobe에서는 64비트 포팅은 다시 빌드하거나 포인터 변수 사용 고치는 정도의 간단한 문제가 아니고 현재 작업중이라고 한다.  가장 쉽고 간단한 방법은 nspluginwrapper를 이용하는 것.  일반 플러그인을 사용하는 것보다 꽤 CPU 로드가 높아서 (그래도 쓸만하지만) 궁극적인 솔루션이라고 할 수는 없다.

duncan:~/tmp$ tar zxvf install_flash_player_9_linux.tar.gz
...
duncan:~/tmp$ cd install_flash_player_9_linux
duncan:~/tmp/install_flash_player_9_linux$ linux32 flashplayer-installer
...
duncan:~/tmp/install_flash_player_9_linux$ nswrapper ~/.mozilla/plugins/libflashplayer.so

Java - 이게 가장 큰 문제이다.  sun java 1.4는 nspluginwrapper로 동작하지만, java5/java6는 동작하지 않는다.  IBM JRE도 AMD64 버전이 없긴 마찬가지이다.  blackdown java는 원래 java5/java6 버전이 없다.  이 문제는 Sun의 게으름과 무관심이 가장 큰 문제이다.  이미 JRE는 amd64로 포팅이 되어 있고 없는 부분은 plugin 인터페이스뿐이다.  flash와는 달리 컴파일만 하면 해결되는 문제라는 얘기다.  J2SE 소스코드를 받아서 고쳐보려다가 참고 그냥 blackdown java만 깔아 놓았다.  이래서 자바가 진작에 오픈소스가 됐어야...

브라우저 문제를 해결하는 가장 현실적인 방법은 32비트로 빌드한 웹브라우저를 사용하는 것이다.  swiftfox를 사용하는 게 한 가지 방법이다.


결론적으로...  현재 새로 까는 사람들은 그냥 32비트 리눅스를 설치하기를 권장 -_-  (과연 ia32는 언제까지 존속할 것인가?)   일단 현재까지의 내용만 정리해서 flash 데비안 패키지도 nswrapper 사용하도록 고쳐서 버그 보내 보고 데비안 imhangul 패키지도 ia32 호환 버전 빌드하고 할 예정. 

데비안의 선호 투표 해석하는 방법

데비안은 가끔 "투표"를 한다. 데비안 개발자라면 투표권이 주어지는데, 마침 2007년 리더 투표가 있었고 어제 Sam Hocevar가 당선되었다는 결과 발표가 있었다.  음 그런데 이 웹페이지를 보면 대체 무슨 소리인지 잘 알기 어렵다. 뭔가 복잡한 용어가 등장하면서 수식이 등장해서 잘 파악하기 어렵다. 나도 처음에는 상당히 생소했기에, 한번 이 글에서 데비안의 투표 방법인 Condorcet method를 설명해 보려고 한다.

투표자의 갈등

우리가 정치 활동을 하면서 하게 되는 투표는 그 방법이 아주 간단하다. 후보가 몇 개가 있으면 그 중에서 자기가 원하는 후보를 하나 찍고 가장 많은 투표를 획득한 후보가 당선/선택된다. 하지만 찬반투표가 아니라면 실제로 우리가 투표를 할 때도 흔히 고민하게 되는 다음과 같은 문제가 있다.

• 사표 방지 심리 - 내가 좋아하는 후보는 따로 있는데, 당선이 안 될 것 같다.  차라리 정책이 비슷하면서 당선 가능성이 있는 사람에게 표를 몰아주고 싶다.
• 절대적 지지 후보 없음 - 이 놈이나 저 놈이나 다 똑같다. 역시 당선 가능성 있는 사람중에 차악을 선택해야 되나?

우리 일상생활의 "한 표"의 행사라는 게 그렇게 고민덩어리이다. 내가 가진 신성한 이 표가 너무 무의미해 보인다. 결국 유행에 밀려 유력 후보를 찍을 수밖에 없고, 정치적인 성향이 분명치 않은 사람은 자기 의견을 투표로 표현하기도 어렵다.

선호 관계 투표

Condrcet method에서는 적어도 위와 같은 고민은 없다.  투표를 할 때 한 사람을 찍는 게 아니라, 여러 명의 선호 관계를 기술하는 방식이기 때문이다.  데비안의 투표 용지를 이용해 보면,

[   ] Choice 1: cwryu
[   ] Choice 2: crew
[   ] Choice 3: clue
[   ] Choice 4: None Of The Above

투표용지는 1234 네 가지의 선택 사이의 선호 관계를 기술하게 된다.  더 선호하는 쪽에 작은 번호를 붙인다.  "2 1 3 4"를 써 넣으면 crew가 cwryu다는 좋다는 이야기이고 cwryu가 clue보다 좋다는 이야기이다.  내가 원하는 후보가 choice 1이지만 당선 가능성이 없다면 그냥 원하는 후보를 1로 쓰고 다음에 차악을 최악보다 우선적으로 선택하면 된다. 

[ 2 ] Choice 1: cwryu
[ 1 ] Choice 2: crew
[ 3 ] Choice 3: clue
[ 4 ] Choice 4: None Of The Above

그래도 좀 나은 후보가 1번인데 2번이나 3번이나 다 똑같은 놈같으면?  Choice 1에 1번을 붙이고 2/3번에 같은 번호를 쓰면 된다.

[ 1 ] Choice 1: cwryu
[ 2 ] Choice 2: crew
[ 2 ] Choice 3: clue
[ 3 ] Choice 4: None Of The Above

개표

왜 이렇게 써 넣어도 내 의견이 반영될 수 있는지, 개표 과정을 설명하면... 

이렇게 수집된 투표는 수 많은 "A to B" 선호의 집합이라고 할 수 있다.  몇 가지 후보 중에서 후보가 A와 B 둘이라고 할 때 A를 B보다 선호하는 사람이 있을 수도 있고 B를 A보다 선호하는 사람이 있을 수 있다.  2007년 리더 투표 페이지의 beat matrix가 그 투표를 모아 놓은 것이다. 그러면 각각의 pair에 대해서 어느쪽을 선호하는 사람이 더 많은 지 생각할 수 있다. 각각의 후보를 node로 하고, 후보 A가 B보다 우세하다는 관계를 A to B의 edge로 표현하면 웹페이지에 나온 그래프가 된다. 

즉 사표 방지심리를 가질 필요없이, 내가 선호하는 후보를 1번으로 기입하면 설령 그 후보가 당선권에서 멀어지더라도, 차악을 선택할 수 있고 그 표가 똑같이 반영된다.  절대적으로 선호하는 후보가 없더라도 특히 싫어하는 후보를 명시한다면 그 후보를 떨어뜨리는 정도로라도 자기 표로 의사를 표현할 수 있다.

애매한 경우

이 그래프가 이번 2007년 리더 투표처럼 한 사람이 모든 사람을 이기면 관계가 없지만 (이런 식으로 결과가 나오는 게 보통), 이 관계가 circular relation이 된다면 복잡해 진다.

이런 상황에서는 (오리지널 Condorcet method는 이 상황에 대한 해결 방법이 없지만) Schulze dropping 방법에 따라 몇 가지 기준에 따라 승자를 결정한다.  첫 번째로 선호 관계에서 얼마나 더 많은 후보를 제쳤느냐가 기준이 된다. 즉 그래프에서 outgoing edge와 incoming edge의 개수를 기준으로 승자를 결정할 수 있다.  그리고 만약에 이걸로도 결정할 수 없는 상황이 된다면, 그렇게 circular relation이 되는 관계만을 추려낸 다음에 가장 약한 (표 차이가 작은) 선호관계를  하나씩 없애서 circular 관계가 아닐 때까지 계속 한다.  예를 들어 A와 B와 C가 circular하게 선호하는 관계라면 A to B, B to C, C to A의 관계중에 가장 약한 관계를 drop한다.

그래도 동률이라면????

...
...

우리나라 국회의원 선거처럼 나이 많은 사람이 당선되는 건가?   -_-

그 상황이 된다면 투표 알고리즘만으로는 해결할 방법이 없다.  그런 상황이 계속해서 벌어진다면, 과연 투표라는 게 인간 사회의 의사결정 방법으로 올바른 방법인지 진지하게 생각해 볼 필요가 있을 듯...

어색한 번역 습관

어색한 메세지 번역을 피하는 팁 몇가지에 이어...서 쓰는 건 아니고 관련 있는 몇 가지 메모:

한자를 붙여 신조어 만들기: 비(非)~, ~자(者), ~기(機)

우리가 일상생활이나 컴퓨터에서 쓰는 단어 중에 분명히 비~, ~자, ~기라는 단어가 있고, 많이 쓰는 건 사실이다.  nonpreemptive/비선점, editor/편집기, constructor/생성자, manager/관리자 등등등..  이러한 단어들이 만들어지게 된 유래가 (상당부분 중국과 일본에서 만든 한자 차용) 옳은지 그른지는 재쳐두고라도, 번역할 때 이러한 단어를 임의로 만드는 일은 정말 바람직하지 않다.   non-free - 비자유?, tokenizer - 구문분석자?, monitor - 감시기?  일단 보기에 어색하다.

이미 익숙하게 쓰는 단어가 아니라면 "비~" prefix가 한글로 붙었을 때 그게 부정의 의미인지 파악하기 어렵고, "~기"나 "~자"를 소프트웨어에 사용하는 것도 우리말에 자연스럽지 않다.

살아있는 소프트웨어

흔히 이야기하는 "수동태를 쓰지 말라"는 번역 팁과 연관있는 이야기로, 우리말에선 생명체가 아닌 존재에 동사를 잘 붙이지 않는다. 무생물은 주체적이지 않다.  (철학적인 문제?)

예를 들어 프로그램의 메세지에서 "I"와 "YOU"를 사용하는 말이 나올 때 상당히 고민하지 않으면 자연스럽게 번역하기 힘들다. 흔히 영문 메세지 원문에서는 소프트웨어가 생명을 가지고 사용자와 대화하는 것처럼 I를 주어로, you를 목적어로 사용하는 경우가 있는데 "나는", "당신은"이라고 번역하기 시작하면 번역 결과물이 상당히 곤란해 진다.

마땅히 무슨 말을 써야 한다는 정답은 없고, 아예 I나 you를 번역문에서 언급하지 않고 충분히 뜻이 통하도록 적당히 번역하는 게 가장 좋은 것 같다.

쓰레드별 POSIX locale

홈디렉토리를 정리하다가 예전에 쓰레드별로 다른 로케일 쓰는 방법을 찾아보다가 작성했던 예제 코드 발견.  glibc 전용이긴 하지만 지금 서치해 보니 darwin에도 구현되어 있다.  (MS에는 GetThreadLocale, SetThreadLocale 따위, 꼭 필요한 상황은 많지 않다 보니 그다지 쓰이지는 않는 듯...)

#define _GNU_SOURCE

#include <pthread.h>
#include <locale.h>
#include <time.h>
#include <stdlib.h>

struct tm tm = { 0, };

void *
thread_func()
{
  char buf[256];
  int n;
  locale_t l;

  l = newlocale(LC_ALL_MASK, "ko_KR.UTF-8", 0);
 
  uselocale(l);
  sleep(1);
  n = strftime(buf, 256, "%b %A %a", &tm);
  buf[n] = '\0';
  puts(buf);
  sleep(1);
  n = strftime(buf, 256, "%b %A %a", &tm);
  buf[n] = '\0';
  puts(buf);
  sleep(1);
  n = strftime(buf, 256, "%b %A %a", &tm);
  buf[n] = '\0';
  puts(buf);
  sleep(1);
  n = strftime(buf, 256, "%b %A %a", &tm);
  buf[n] = '\0';
  puts(buf);
  uselocale(LC_GLOBAL_LOCALE);
  freelocale(l);
}

int
main(int argc, char *argv[])
{
  pthread_t t;
  char buf[256];
  int n;

  setlocale(LC_ALL, "C");

  pthread_create(&t, 0, thread_func, 0);
  pthread_detach(t);
  sleep(1);
  n = strftime(buf, 256, "%b %A %a", &tm);
  buf[n] = '\0';
  puts(buf);
  sleep(1);
  n = strftime(buf, 256, "%b %A %a", &tm);
  buf[n] = '\0';
  puts(buf);
  sleep(1);
  n = strftime(buf, 256, "%b %A %a", &tm);
  buf[n] = '\0';
  puts(buf);
  sleep(1);
  n = strftime(buf, 256, "%b %A %a", &tm);
  buf[n] = '\0';
  puts(buf);
 
}

실행해 보면 이렇게 두 개 스레드가 다른 로케일을 사용한다.

$ ./a.out
Jan Sunday Sun
 1월 일요일 일
Jan Sunday Sun
 1월 일요일 일
Jan Sunday Sun
 1월 일요일 일
Jan Sunday Sun

데비안 문제 (3) - 메인테이너와 패키지에 대한 권한

데비안 문제 (1) - unstable,
데비안 문제 (2) - 새 패키지 큐와 FTP 마스터 에 이어..

데비안 메인테이너가 된다는 건 무엇을 말하는 걸까?  free software project에서 보기 드문 복잡한 테스트를 거쳐서 "DD"가 되면  "@debian.org" 메일 주소를 가지고 있으며, 데비안 머신에 계정을 이용할 수 있고, debian-private 메일링 리스트에서 공개되지 않은 플레임^H^H^H메세지를 읽을 수 있고 (3년 후 공개된다), 각종 투표에 한 표를 행사할 수 있다.  하지만 '메인테이너'란 말 그대로 패키지의 메인테인 권한을 갖는 게 가장 큰 부분이다.

데비안 프로젝트가 이렇게 발전한 데는, 배포판을 다루고 있다는 점과 패키지 시스템이 잘 만들어져 있다는 점이 큰 몫을 했다.  각각을 패키지 단위로 쪼개고 각 패키지를 한 명의 메인테이너에게 배정할 수 있기 때문에 (패키지의 Maintainer: 필드가 있다는 점) 데비안의 scalability에 큰 영향을 미쳤다.  세계 어디에 1000명이나 되는 개발자가 한 가지 목표를 위해 참여하고 있는 OSS 프로젝트가 있을까?  물론 패키지 사이에 복잡한 상호관계가 (의존, 충돌 등등) 있긴 하지만 다른 사람이 어떤 작업을 하고 있는지 거의 몰라도 패키지를 만드는 데는 문제가 없는 경우가 많다.  그래서 보면 패키지 한 두개만을 담당하면서 메일링 리스트도 거의 읽지 않고 자기만의 세계에 빠져서 그 패키지만 업데이트하는 걸로 메인테이너를 유지하는 사람들도 꽤 있다.

이 데비안의 scalability와 패키지간의 독립성이 갖는 장점이 조금씩 상처를 받게 된 건 최근인 것 같다.  먼저 사람 수가 몇배가 넘게 늘었고, 리눅스에서 돌아가는 프로그램들이 의존성을 두려워하지 않는다.  과거에는 그야말로 라이브러리라고는 libc에만 의존하는 프로그램이 상당수였고, 기껏해야 bdb를 사용하고 X 프로그램이래봐야 X11, 조금 복잡하면 Xt/Xaw를 사용하는 정도로 의존성을 늘이는 데 주저하는 경향이 있었지만 요즘은 그렇지 않다.  서슴치 않고 라이브러리를 이용한다.  이제는 메인테이너들 사이에 긴밀한 협조가 필요하다.

그런데 종종 메인테이너가 시간이 없거나, 실력이 부족하거나, 아니면 성격이 괴팍하다고 밖에 볼 수 없는 이유로  협조가 제대로 되지 않는 일이 발생한다.  오랜 시간동안 메인테이너가 응답하지 않아서 버그 수정이 제대로 되지 않는 일이야 흔한 일이고, 버그를 수정하지 못하는 경우도 많다.  이런 상황이 벌어졌을 때 나름대로 도움을 요청하거나 "NMU 해 버려"라고 하는 아량을 가졌다면 괜찮은데 그것도 아니고 질질 끄는 상태가 되기도 한다.  또 정말 "나쁜" 메인테이너는 "그게 왜 버그냐. 건드리지 마"식으로 일관하는 사람도 분명 있다.  사람 사는 곳이야 어디나 괴팍한 사람도 있게 마련이지만, 그런 일이 발생했을 때 특정 패키지, 특히 중요한 패키지 몇개가 다른 패키지를 따라가지 못하는 상황에 빠지면 난감하기 짝이 없다.  (예를 들어 보면, 데비안의 GDM 패키지는 다른 gnome 패키지처럼 유기적으로 움직이지 않는다.)

이러한 강력한 메인테이너쉽은 제도적인 근거도 있다.  constitution 3.1에 규정된 바에 따르면 "An Individual Developer may make any technical or nontechnical decision with regard to their own work".  물론 이 권한을 override할 수 있는 권한이 테크니컬 커미티에게 있다: "The Technical Committee may ask a Developer to take a particular technical course of action even if the Developer does not wish to; this requires a 3:1 majority. For example, the Committee may determine that a complaint made by the submitter of a bug is justified and that the submitter's proposed solution should be implemented."  하지만 커미티의 이 권한 행사는 실제적으로 이루어지기 힘들다. 3:1 의견이 나오기도 쉽지 않은 일이지만, constitution 규정이 만들어진 이후로 수십배로 커진 데비안의 규모에 따라 그만큼 늘어난 각종 갈등에 대응하기도 어렵다.  실제로 지금까지 커미티가 결정한 사항도 라이센스 문제이거나, debian-policy의 명백한 위반처럼 사안이 명확하고 어떻게 결정해야 할 지도 명확한 것 외에는 개발자의 권한을 오버라이드하는 경우는 찾아볼 수 없다.  정답이 명확하지 않은 각종 정책적인 결정사항에 대해서는 그냥 패키지 담당 메인테이너에 따라 결정될 가능성이 99.99%이다.

아마도 우분투처럼 모든 패키지를 소스컨트롤하고, 모든 개발자에게 쓰기 권한을 주는 일은 데비안에서는 일어나지 않을 것 같다.  하지만 어떤 식으로든 메인테이너의 "패키지 소유"는 좀 약화시킬 필요가 있다.  실제로 패키지에 Uploaders: 필드가 구현되서 여러명이 권한을 가지는 Co-maintenance 방법도 있고 (실제로 잘 이용하고 있음), 스스로 권한을 축소시키는 Low Threshold NMU 방법도 있었다.  링크는 잊어버렸지만, 일단 etch 릴리스한 다음에 개인의 권한에 대해 constitution 개정을 시도하겠다는 제안도 있었다.  (실현은 어려울 것 같지만)

일단 나도 이러한 데비안의 "지나친 메인테이너쉽" 문제를 개선하는데 조금이라도 기여하기 위해..  메인테인하고 있는 모든 패키지를 alioth 등 데비안의 소스컨트롤에 등록할 예정이다.  그리고 가능하다면 원하는 모든 사람들에게 커미트 권한과 업로드 권한을 부여한다.  이 정도가 현재 할 수 있는 일이다.  (내 하드 디스크에서 계속 소스 관리하기가 피곤해서이기도 하고...)

Tomboy의 날짜/시간 포맷 오류 - mono locale 관련

Tomboy를 실행하다가 날짜와 시간이 한국 포맷으로 나오지 않는 것을 발견해서 예전의 퍼키옹이 한 경로를 그대로 추적을 해 봤습니다. 막상 이걸 봐도 실제로 문제점을 추적하기는 힘들더군요.  그래서 일단 버그부터 지른다음에 조금 기다려봤는데...  역시 그냥 버그 현상만 써 놓으니까 메인테이너도 고쳐주질 않을 것 같고 퍼키씨도 당장은 손 안 대는 것 같고 해서 직접 찾아봤습니다.

결국 퍼키옹이 따라갔던 경로를 하나하나 다 반복해 보고서는 문제를 파악했는데..  문제는 헤더 파일을 제너레이트하는 C# 프로그램이 소팅을 하면서 "ko-kr"을 "kok" (콘칸어) 뒤에 배치하는 바람에 C 코드에서 strcmp로 바이너리 서치를 할 때 못 찾는 문제였습니다.  String.CompareTo()를 간단히 String.CompareOrdinal()로 교체해서 해결.

그런데 여기서 끝나지 않은 게, 빌드를 잘못했는지 이제 각각의 "1월", "2월", "월요일" 따위의 이름은 한글로 나오는데 포맷이 어떤 부분은 제대로 나오고, 어떤 부분은 "12월 6 2006"과 같이 나오네요.

(업데이트) 나머지 문제는 C# culture info와 상관없이 tomboy에서 자체적으로 사용한 날짜 포맷을 번역할 때 고려하지 않은 사항.  tomboy 번역을 바로잡았으니 다음 릴리즈에는 제대로 나오겠네요.

구글 blogger.com - 한국 포털 블로그와의 잘 보이지 않는 장벽

뭐랄까.  구글은 디자인이나 사용성 등 기발한 상상력보다는 노동력이 투입되는 부분에 약한 면이 있다.  다른 글 읽으려고 blogger.com에 들어갔다가 오른쪽 위에서 자꾸 만들 수 있다고 유혹을 하길래 만들어 봤더니...

일단 뭔가 알 수 없는 어색함을 느낀다.  기계적인 번역만을 한 상태이고, 한국말로 사용성 테스트가 제대로 되지 않은 듯 하다.

이렇게 어색한 번역도 그렇고..  확실히 테스트가 안 된 것처럼 정렬도 영문 순서로 되어 있다.

나도 한국 포털의 인위적 조작에 대해 상당히 반감을 갖고 있지만, 이런 건 사람이 노동력을 좀 투입해 줘야..  -_-

(일단 한국말로 보면 어색하다는 거 빼고는.. 온갖 기능들은 상당히 뛰어나다.)

HTML5에 OGG Theora?

whatwg에서,

"User agents should support Ogg Theora video and Ogg Vorbis audio, as well as the Ogg container format."

저 문구가 should가 된다면, 사실상 OGG만 쓰게 된다는 얘기나 다름없어진다.  하긴 MPEG은 특허 문제에 휘둘릴게 뻔하니까 (정작 표준이지만)  오픈소스 브라우저를 만드는 사람들이 크게 반대할 것이다.

(동영상 사이트들 OGG 좀 지원해 주시지...)

배포판 중심 메세지 번역의 폐해 - 커뮤니케이션 부재

과거에도 그랬듯이, 배포판 중심의 메세지 번역은 보통 그 배포판 안에서만 사용되고 그 안에서 수명을 다한다.

우분투의 런치패드/로제타는 온라인 메세지 번역 시스템으로 기술적으로는 내가 생각했던 이상적인 모습이지만, 배포판 중심의 번역 운영은 (한국이든 세계 어디든) 커뮤니케이션의 문제를 가질 수밖에 없다. 예전에 런치패드/로제타에 의해 한국어 번역이 시작되었을 때 내가 우려했던 것처럼 업스트림과 따로 노는 현상이 벌어지곤 한다.

간단히 예를 들어 우분투 feisty의 한국어 번역 중에서 KDE 관련 프로그램은 로제타에서 많은 부분이 번역되어 있다.  많은 부분이 비슷한 모습을 보이지만, 꽤 많이 번역된 일부분을 보면,

그럼 KDE upstream의 한국어 통계를 들어가서 이 부분이 업스트림에 어떻게 되어 있는 지 확인해 보자.  위에 나온 kdebase를 비교해 보면 다음과 같다.  거의 반영이 되어 있지 않다.

그럼 보너스로 또 한 가지 비교해 보자.  한소프트리눅스는 어떨까?  한소프트리눅스 오픈 프로젝트에서 kde-i18n 패키지의 src.rpm 파일을 받아서 확인해 보았다.

zeus:~/tmp/kdebase/kde-i18n-ko-3.5.6/messages/kdebase$ for X in kcm*po; do msgfmt --stat $X -o /dev/null; done
번역된 메시지 70개.
번역된 메시지 47개.
번역된 메시지 68개.
번역된 메시지 121개.
번역된 메시지 21개.
번역된 메시지 8개.
번역된 메시지 67개.
번역된 메시지 34개.
번역된 메시지 180개.
...

어라?  -_-  완벽한데 대체 무슨 일이 벌어진 것일까?  과연 누가 이걸 번역했는지 알아보기 위해 PO 파일의 Last-Translator: 엔트리를 찾아보았다.

zeus:~/tmp/kdebase/kde-i18n-ko-3.5.6/messages/kdebase$ grep Last-Translator: kcm*po
kcmaccess.po:"Last-Translator: root <root@localhost.localdomain>\n"
kcmaccessibility.po:"Last-Translator: root <root@localhost.localdomain>\n"
kcmarts.po:"Last-Translator: root <root@localhost.localdomain>\n"
kcmbackground.po:"Last-Translator: root <root@localhost.localdomain>\n"
kcmbell.po:"Last-Translator: root <root@localhost.localdomain>\n"
kcmcgi.po:"Last-Translator: root <root@localhost.localdomain>\n"
kcmcolors.po:"Last-Translator: root <root@localhost.localdomain>\n"
kcmcomponentchooser.po:"Last-Translator: root <root@localhost.localdomain>\n"
kcmcrypto.po:"Last-Translator: root <root@localhost.localdomain>\n"
...

다름 아닌 한소프트리눅스 측에서 자체 번역한 결과물이다.  (위의 결과로 알 수 있는 사실, 번역자는 루트 계정으로 KBabel을 이용해 번역한다.)  이것이 한소프트리눅스 광고에 등장하곤 하는 "전문 번역팀을 통해 자연스럽지 못했던 한글 번역부분을 말끔히 개선하였습니다"의 실체인가?

"위와 같은 꼴"을 보고 절대 잘 한다는 소리는 절대 못하겠지만, 어제 오늘의 일이 아니고 이제는 적어도 이해는 할 수 있다.  FOSDEM 2007의 비디오 중에서 리눅스 커널에 관한 세션을 보면 이런 얘기가 있다 -- "임베디드 분야의 리눅스 커널의 발전이 더딘 이유는 피드백이 없기 때문인데, 칩 메이커를 제외하고 완제품을 만드는 제조업체들은 제품의 개발기간도 짧은 데다가 스펙이 한정되어 있고 소프트웨어 업데이트도 거의 없기 때문에 피드백의 현실적인 필요가 적다".  배포판 업체들도 마찬가지이다.  번역에 관한한 충분한 맨파워를 동원할 수 있다면 (우분투와 한소프트리눅스는 그 방법을 다르게 취한 것 같지만) 업스트림 피드백으로 얻을 건 별로 많지 않다.  런치패드/로제타의 자발적인 참여자들도 자기들의 번역 결과물이 자기가 사용하는 OS에 반영되는 것만으로도 상당히 만족하고, 또 다른 업스트림에 반영하는 건 런치패드/로제타보다 진입장벽이 높기 때문에 부담스러워하는 것도 같다.

이 상황을 어떻게 해결해야 하나.  업스트림에 번역을 반영하는 장벽을 낮추는 게 한 가지 방법이지만, 어떻게 쉽게 컨트롤할 수 없는 부분이다. 적어도 내가 상당부분을 컨트롤하고 있는 그놈 / 데비안 번역은 가능할 것도 같은데, 앞으로 생각할 부분이다..

메세지 번역에서 흔히 발생하는 문제와 해결

보안용 장비를 만들 시절에, 회사에서 번역 업체를 많이 이용했었다.  이 번역업체는 세계 곳곳의 각 언어권마다 지사를 두고 있는데 각 지사마다 네티이브 번역자가 있는 동시에 그 지역의 번역 의뢰자를 상대로 영업을 한다.  번역 의뢰가 들어오면 원문을 각 세계 지사에 보내서 네이티브들이 번역을 하게 만든 다음 번역한 결과물을 모아서 의뢰자에게 돌려준다. 이런 식으로 동작하는 번역 전문 회사가 꽤 많이 있고, 이 방식으로 꽤 괜찮은 품질의 번역을 빠르게 만들어 낼 수 있다. 보통 제품을 릴리스할 때마다 백여개 내외의 메세지가 독일어, 프랑스어, 이탈리아어, 스페인어, 일본어로 5개국 번역이 되었는데 (정확하진 않지만) 60-70여만원정도가 필요했다.  (그러면 GNOME 2.18의 한국어 메세지는 35000여개가 되므로 이 계산법에 따르면 수억의 가치가 있다고 할 수 있다. ^^)

그 번역 업체는 IT 전문 번역을 표방했고 상당히 많은 경험이 있는 것으로 보였다.  하지만, 번역이라는 건 그렇게 뚝딱 할 수 있는 게 아니다. 번역이라는 작업은 한계가 있다.

1. 번역자가 CCTV 시스템에 대한 지식이 부족했다.  예를 들어 전통적인 보안 시스템에서 NC/NO는 Normally Close, Normally Open으로 보안용 센서의 종류를 나타내는 말로 "붙은" 상태가 정상인가 "떨어진" 상태가 정상인가를 나타내는 말이다.  (예를 들어 출입문에 부착하는 접점 센서는 닫혔을 때 즉 붙은 상태가 정상이고 문을 열면 떨어지면서 센서가 activate된다.) 하지만 많은 번역자가 NC를 (유행이 한참 지난 용어인) Network Computer라고 번역하기 십상이었고 NO를 Number의 약자로 번역하기 십상이었다.

2. 꽤 오랜 기간동안 제품을 업데이트하다 보니 번역을 하면서 일관성이 맞지 않는 부분이 많이 발생했다.  의뢰인인 우리쪽 입장에서는 사실 누가 번역했는지는 알 수도 없고 신경도 안 쓰는데, 같은 용어를 여기저기서 다르게 사용한다든지 말투가 달라진다든지 하는 일이 그 언어를 전혀 모르는데도 뻔히 알 수 있을 정도로 자주 발생했다.

3. 번역 업체와는 상관없지만 번역한 결과를 적용할 때마다 언제나 화면 크기의 부족에 시달렸다.  작은 NTSC/PAL TV 화면의 크기에 맞춰야 하는 입장에서는 난감하기 짝이 없었다.  화면상의 각종 컨트롤의 크기를 dynamic하게 만들고 복잡한 클리핑과 스크롤 기능으로 보완해 보려고 했지만 결국 한계가 있었고, 특히 이탈리아어와 스페인어의 경우 점(.)으로 단어를 줄여쓴 (Abracatabra라면 Abra. 식으로) 신조어 레이블이 화면의 많은 부분을 차지하게 되었다.

옛날 얘기는 여기까지 하고 현재로 돌아와서, 위의 현상은 오픈소스 소프트웨어의 메세지 번역에도 똑같이 적용된다.  얼마전에 그놈 2.18이 릴리스되었지만, 여전히 (1) 메세지의 일부는 해당 프로그램의 기능에 대해 잘 이해하지 못한 부분때문에 오역이 있고, (2) 업데이트하면서 가끔 말투와 용어를 다르게 쓰기도 하며, (3) UI의 문제때문에 번역해 놓은 모양이 아주 보기 나쁜 경우가 많이 있다.  이와 같은 실수는 번역자의 실력과 경험에 따라 달라지겠지만 여전히 발생한다.

이와 같은 문제를 100% 없애기는 쉽지 않다.  실제로 마이크로소프트가 공개한 마이크로소프트가 릴리스하는 번역문도 하나하나 살펴보면 어색한 번역문도 있고 오역이라고 생각되는 번역문도 꽤 있으며 시간이 지나면서 다른 용어를 사용하는 부분도 꽤 보인다. 하지만 그 번역문 중에서도 자주 사용하는 마이크로소프트의 대부분의 번역문은 아주 매끄러운데, 이는 다름 아니라 엄청난 사용성 테스트의 결과물이다.  역시 피드백을 많이 받아서 계속해서 다듬어 나가면 잘 번역했다는 소리를 들을 수 있다는 얘기이다. 하지만 역시 보안 장비를 만들 때나 그놈 메세지를 번역할 때나 자기 스스로 깨닫고 고치는 것 외에 외부에서 피드백을 받기는 쉽지 않은 일이다. 그놈 메세지는 특히, 심심풀이 작업때문에 일부러 프로그램 테스트를 심각하게 할 수는 없는 노릇이다.

그래서 앞으로 그놈 및 내가 참여하는 번역은 번역자들의 (특히 류모씨의) 부담을 줄이면서도 좀 더 많은 참여와 피드백을 받고 번역을 다듬을 수 있는 방법을 찾아 보려고 한다. 어떤 게 될 지는 나도 아직 잘 모르겠으므로 다음 시간에...

데비안 문제 (2) - 새 패키지 큐와 FTP 마스터

데비안 문제 (1) - unstable에 이어,

libhangul이 데비안 아카이브에 들어가는 데 두 달이 걸렸다.  한달 후에 거부되었다는 메일이 왔고, 또 다시 한 달이 걸렸다.  거부되었던 이유는 hanja.txt 파일의 라이센스가 3 clause BSD였기 때문.  자 한 달이 걸린다.

나는 근본적인 의문을 제기할 수밖에 없다.  왜 추가적인 검사가 필요한가?  물론 소프트웨어가 데비안 아카이브에 들어가서 전세계에 미러링될 때는 심각하게 고려해야 할 사항이 많다.  행여나 재배포가 불가능한 소프트웨어를 업로드했다가 문제가 되면 난감한 일이다.

하지만 대체 왜 소수의 라이센스 점검 작업자가 필요한 것일까?  까다롭기로 유명한 데비안의 뉴 메인테이너 프로세스를 통과할 정도이면 뭐가 DFSG에 맞고 아니고 정도는 아는 것 아닌가?  (그 전에 DD가 된 사람이야 워낙 오래됐으니까 :P)  어차피 데비안은 각각의 메인테이너를 신뢰하지 않으면 존재할 수 없는 시스템이다.  게다가 새로 올라오는 패키지의 90% 이상은 라이센스가 GPL/LGPL/MPL/BSD/MIT 따위이다.

설령 라이센스가 잘못된 상황이더라도 데비안은 지금까지 끊임없이 라이센스에 대해 문제를 제기하고 고쳐나가 왔다.  법적인 문제만을 토론하는 메일링 리스트가 따로 있고, Qt&KDE, 파이어폭스/아이스위즐, GFDL, mplayer 등등 다른 사람들이 신경쓰지 않는 문제들까지 라이센스 문제라면 지나칠 정도로 앞장서서 행동을 취해 왔다.  이정도의 충분한 자정능력이 있는데도 소수의 팀이 수백개의 새로운 패키지를 큐에 쌓아놓고 라이센스를 찬찬히 뜯어보는 수고를 할 필요가 있는 것일까?  한 순간의 미러링도 법적 문제를 유발할 수 있다고 하지만, 이미 그렇게 한순간 문제되는 소프트웨어가 미러된 상황은 과거에도 많았다.  하지만 파이어폭스 상표권때문에 모질라재단이 "과거" 한순간에 배포되었던 (수정된) 파이어폭스를 가지고 소송을 걸까?  아니면 개인 개발자가 라이센스는 자기 의도와는 다르게 잘못 고지"했었던" 데비안에게 책임을 물을까?  실수로 자바 런타임이 다른 섹션에 들어가서 세계 어디에선가 CD로 재배포"했었다고" 썬이나 IBM이 시비를 걸까?   technically 문제가 발생할 수 있지만 practically 그것때문에 법적 책임을 물어야 할 일은 발생하지 않는다.  (하지만 바로 그 이론적으로 책임을 물을 수 있다는 것 때문에 이 방식을 버리지 못하고 있다.)

그래도 과거에 1인이 처리했던 것에 비하면 지금의 팀워크때문에 비교적 큐가 비워지는 속도가 일정해서 다행이긴 하지만, 갈수록 큐가 늘어나는 속도가 빨라지는데 거기에 맞춰서 (재미없는) 작업을 할 FTP 마스터들을 충원하기도 쉽지 않은 일이다.  내 생각은 일단 없애 보자는 것.

구글 SoC2007 for 그놈, 포스터 번역

심심풀이 구글 SoC2007 그놈 포스터 번역

http://live.gnome.org/SummerOfCode2007/Poster

데비안 문제 (1) - unstable

"누가 unstable을 stable하게 만들었는가"

데비안을 써 본 사람이라면 알겠지만, unstable이라고 붙어 있는 배포판은 사실 전혀 unstable하지 않다.  잘 모르는 사람들은 unstable이라는 말을 보고 두려워하겠지만, 아마 최근에만 unstable을 사용해 본 사람이라면 왜 이걸 unstable이라고 부르는지 의문을 가질 것이다.

일단 안정한 건 나쁠 이유가 없다.  하지만 stability를 지키려면 새 기능들의 빠른 도입을 희생할 수밖에 없다.  그놈 데스크탑과 각종 프로그램들이 업스트림과 반년 이상 차이가 난다는 건 참기 힘든 상황이다.  왜 이미 업스트림에서 릴리스된지 몇달 된 프로그램을 experimental에서 찾아야 하는지?  원래 unstable은 이렇지 않았다.

문제는 testing의 탄생과 더불어 시작됐다.  testing은 릴리스 품질의 패키지를 걸러내기 위한 자동화된 수단으로 unstable에서 패키지 사이의 의존성 관계가 올바르고 릴리스 크리티컬 버그가 일정기간동안 없으면 자동으로 testing dist로 넘어간다.  여기까지는 좋은데, 이런 시스템때문에 unstable의 패키지 관리자들 조차 너무 몸을 사린다.  당연히 unstable의 지나친 안정성때문에 up-to-date가 늦어지는 프로그램은 데스크탑 프로그램들처럼 의존성 관계가 복잡하게 얽힌 프로그램들이다.

이제 좀 unstable을 망가뜨려 보면 안 될까?

FOSDEM의 자바 프리젠테이션 중 몇 마디

FOSDEM 비디오 중에서 썬의 "Liberating Java" 프리젠테이션을 보다가 맨 앞에 소프트웨어 특허에 관해서 이야기하다가 나온 이야기:

특허를 출원하는 이유는, 미국 사람들이 총을 구입하는 이유와 비슷합니다.  미국 사람들이 총을 구입하는 이유는, 미국 사람들이 총을 구입하기 때문입니다.  미국 소프트웨어 회사들이 특허를 출원하는 이유도, 미국 소프트웨어 회사들이 특허를 출원하기 때문입니다.

공감 100%.  지금까지 경험한 회사가 비교적 작은 회사였기 때문이었을까?  지금까지 회사에서 특허에 관한 교육이나 특허에 관한 이야기가 나올 때마다 항상 처음에 소개하면서 듣는 이야기는, "특허가 없으면 특허 분쟁이 발생했을 때 X된다"였다.

(이 비디오에는 그 외에도 자바 이슈에 관심있는 사람이라면 재미있는 내용이 많다)

Seahorse 번역

그놈 데스크탑 2.18에 포함될 프로그램으로 가장 작업량이 많았던 Seahorse 번역을 마쳤다.  700여개..

위에서도 "Full"과 같이 번역이 안 되어 나오는데, 프로그램 문제로 번역 안 되는 부분이 아주 많은 게 문제이다.  릴리스된 뒤에도 여기저기 번역 안 되는 버그를 잘 찾아봐야 할 듯 하다.  애플릿은 아예 전체가 번역이 안 되어 나온다.  다음은 애플릿을 이용해 클립보드의 내용에 서명을 붙인 것.

문제는 키링에 키가 많을 때 GPG가 시스템 대부분의 로드를 먹으면서 엄청나게 느려지는 현상이 있다.  내 키링이 기껏해야 300개 내외인데 이런 현상이 벌어진다.  (키링이 이보다 더 큰  키사이닝파티 매니아가 과연 seahorse를 사용할 지는 모르겠지만.)  상당히 featureful한 건 맞고 도움말 문서도 훌륭하지만 안정성은 좀 떨어져 보인다...

번역하면서 재미있는 기능을 발견했는데, DNS-SD(애플 랑데뷰/봉쥬르)를 이용해 네트워크에 자기 pubkey 키링을 export하고, 네트워크 안에서 seahorse를 사용하고 있는 사람들끼리 pubkey를 교환할 수 있다!  실험은 못 하지만 사무실/연구실같은 환경에서 사용했을 때 상당히 괜찮은 기능으로 보인다.

그놈 데스크탑 L10N의 과제

한번 그놈 데스크탑의 한국어 지원 상태와 과제에 대해 정리해 보았다.

번역

메세지 번역 업데이트, 다듬기 - 그놈 데스크탑의 한국어 메세지 번역은 그놈 역사와 함꼐 버전이 0.x일 때부터 시작되어 지금 거의 10년 가까이 계속되었다.  요즘에는 릴리스 노트에서도 "supported language"라고 선전을 하는데, 애초부터 "지원하는" 언어였다.  오랜시간 작업하면서 나름대로의 일관성도 생겼고, KPC같은 툴의 도움도 컸다.  메세지 번역은 완성도가 꽤 높다고 자부하지만.. 아무래도 번역자가 직접 사용하지 않는 프로그램의 번역 완성도는 상대적으로 높지 않다.  예를 들어 gnome-games에 있는 번역들은 번역하기도 힘들게 만들어 놓은 부분도 있고, 게임을 이해하지 못한 부분이 많다.  또 일반적인 데스크탑 사용자가 사용하지 않는 sabayon 따위는 제대로 돌아가기는 하는지 알 길이 없다.  다양하게 그놈을 활용하는 사람들의 좀 더 많은 피드백과 참여가 필요하다.  또 FDO 등 그놈 번역 통계에 잡히지 않지만 데스크탑에서 사용하는 메세지도 번역할 필요가 있다.

도움말 번역 - 도움말 번역은 썬이 상당히 해 주었는데, 썬의 작업은 JDS/Solaris/OpenSolaris를 타겟으로 하다 보니 그놈 릴리스와 스케줄이 맞지 않고, 숫자로 봐도 매우 저조하고. 메세지 번역과 맞지 않는 면이 있다.  지금 번역된 숫자가 0에 가깝지만 PO 파일 기반으로 바뀌면서 기존 썬의 XML 번역이 PO로 변환되지 않은 상태로 남아 있어서 정확한 숫자는 아니다...   아마 지금부터 준비하면 올해 9월 릴리스에는 어느정도 할 수 있지 않을까?

웹사이트 번역 - 이제 그놈 웹사이트도 다음번 릴리스 타겟으로 Plone CMS를 이용하도록 개편될 예정이다.  개편의 목표 하나가 다국어 사이트이니까 웹사이트에 있는 내용의 번역도 필요해졌다.


그놈 관련 개발

입력기 통합 - 이상한 방향으로 논의만 있던 상태이지만, 입력기 프레임워크를 데스크탑에 통합하는 데 참여한다.  방향조차 애매한 상태라서 갈길이 멀지만, 지금보다 더 그놈 환경에 잘 통합되도록 만들 필요가 있다.  예를 들어서 알림 영역에 입력기 UI가 들어간다든지, 별도 설정 파일에 설정사항을 저장한다든지, 언어별로 다른 프로그램이 동작한다든지 하는 건 범용성을 위한 것이지, 그놈 데스크탑에 잘 통합된 형태는 아니다.

접근성 관련 작업 - 현재 Orca나 GOK같은 접근성 관련 소프트웨어는 메세지 번역만 됐을 뿐이지 실제 한글 입/출력 환경에서 동작할 수는 없다.   (dasher는 첫가끝 코드 덕분에 꽤 쓸만하게 동작한다.)  orca같은 경우에는 TTS 소프트웨어가 필요하고 (아래에서 다시), GOK는 조금 동작하겠지만 키보드 입력이 불편한 사람들이 한글 입력을 어떻게 할 지에 대해 다른 non-free 소프트웨어도 참고하는 등 연구가 좀 필요하다.  당장 수요가 거의 없다고 생각되거나 최소한 알려져 있지 않기 때문에 무턱대고 노력을 투자하기도 힘든 부분이다.  (혹시 자신이나 주변 분들이 그놈의 접근성 관련 기능들을 이용하고 있거나 이용할 필요가 있다면 알려 주시길..)

버그, 버그, ... - 끊임없는 버그 찾기 및 고치기.


일반 한국어 관련 개발

쓸만한 한글 정자체 글꼴 - 바람직한 라이센스에, 품질이 높고, 모든 한국어 유니코드 영역을 커버하면서, 계속 메인테인되는 정자체 글꼴이 있었으면 좋겠다.  (현존하는 글꼴들이 과연 여기에서 뭐가 부족할까?)

철자 검사 프로그램 - kts 등의 문제를 해결하고 쓸만한 상태로 끌어올리거나 새로 만들어도 좋다.  다른 프로그램과 연동해서 사용할 수 있도록 gnome-spell, Enchant 등 다른 소프트웨어에 통합하는 작업도 필요하다.

Text To Speech - Orca 따위에 필요하다. 


기타 개발

하드웨어 지원 - 한국 컴퓨터 시장에서 볼 수 있는 TV 수신 카드, 화상 카메라, 디지탈 카메라 등의 하드웨어들이 리눅스에서 지원되도록 한다.  직접적인 L10N이라고 할 수는 없지만, 그 하드웨어를 이용하는 그놈 프로그램들을 한국 사용자가 쉽게 사용할 수 있게 만드는 일이 된다.  (Ekiga, gnome-volume-manager 등)  한국 시장의 노트북 컴퓨터들의 전원 관리 문제들을 잘 보고하고 도움을 주는 일도 그놈의 전원 관리 기능 향상에 도움이 된다.


커뮤니티

이제 공식 웹사이트에 한국어 번역이 들어간다면 로컬 사이트가 해야 할 일은?  사용자 사이의 의사소통이 가장 크다.  또 하나의 언어 장벽이 될 수밖에 없는 버그질라 등의 다리 역할을 하면서 사용자 의견을 받아들이고 로컬 사용자 모임으로 역할을 해야 한다.  최근 gnome.or.kr의 개편이 있었으니 잘 되리라 믿는다.

만국 공통

직접 들은 말들 모음:

이탈리아인: 역시 여기에서도 제한속도 60이면 70으로 달리는 군.  나도 이탈리아에서 그정도로 달려.
아르헨티아인: 역시 다 제한속도보다 빨리 달리는 구나.
미국인: 제한속도보다 느리게 달리면 벌금 매기지 않아?

독일인: 아 여자친구랑 쇼핑 같이 하면 짜증나.  사지도 않을 거면서 여기저기 구경만 하고.
미국인: 그건 나도 그래.  어쩔 수 없어.  싫어도 같이 해 줘야 돼.

일본인: 근데 이거 정부기관이 처리하는 거라서 좀 느릴거야.  정부라는 건 느려터졌거든.
대만인: 우리 정부도 느려.
한국인: 당연히 한국 정부도.
일본인: 정부는 세계 어디에서나 다 느려.

혹시 "한국 차들은 속도 안지켜", "한국 여자들은 왜 그래", "한국 공무원들은 하여간 느려터졌어"라는 말을 들은 적이 없는지?  혹시 이렇게 "한국 xxx은..."이라는 말들을 너무 자연스럽게 받아들이는 건 아닌지?

길에 돈이 떨어져 있어도 안 줍고, 객관식 문제 답을 모르면 비워둔다고?  어떤 문제이든 "문화적 차이"를 그 원인으로 돌리면 그 문제는 아주 간단해 진다.  문화는 그냥 현실이니까, 그리고 우리나라가 오래동안 그렇게 해 온 현실이니까, 더이상 원인을 탐구할 필요도 없고 그 문제를 해결할 방법도 마땅치 않다.  이렇게 문제의 원인을 간단하게 만들기 위해, 사람들은 흔히 "한국에서는", "한국 사람들은", "외국에서는" 이라는 말을 외국의 현실과 제대로 비교해 본 것도 아니면서 너무도 손쉽게 사용한다.  (그게 근거없는 한국 비하이든, 근거없는 외국 비하이든 간에...)

천만의 말씀이다.  돈도 주워가고, 객관식 문제는 당연히 찍는다.  과연 "선진국에선" 엘리베이터에서 닫힘 버튼을 안 누를까?  인간은 어디에 살든 그렇게 크게 다르지 않다.

마법사와 드루이드

glade3 번역을 하다가 잠깐 든 생각..

그놈 UI 위젯의 하나로 GnomeDruid라는 것이 있다.  프로그램을 처음 실행했을 때 여러가지 설정을 순서대로 한다든지 할 때 사용하는 GUI 위젯으로, "다음"/"이전" 단추를 눌러가며 순서대로 복잡한 설정을 해 나갈 때 쓰는 위젯이다.  당연히 이 위젯은 "마법사"(Wizard)의 패러디이다.

하지만 아마 한국말로 그놈 프로그램을 사용하고 있는 사람들은 "마법사"만 볼 뿐이지 드루이드라는 말은 본 적이 없었을 것이다.  아무리 원문에서 Druid라고 해도 마법사라고 번역할 수밖에 없었다.  위저드나 드루이드 모두 우리 문화에서는 존재하지 않았던 것이지만, 외래 문화의 수입으로 "마법사"는 많이 알려졌다.  또 마이크로소프트가 "마법사"라는 GUI가 이런 것이다라는 걸 많이 주입을 시켰기 때문에 "마법사"라는 용어가 자연스럽게 받아들여진다.  아마 판타지 소설이나 게임을 통해 접한 사람이 아니라면, 드루이드라는 게 무엇인지 모르는 한국 사람이 대부분이고 알더라도 마법사가 들어갈 자리에 드루이드를 쓴다면 혼란을 일으킬 것이다.

하지만 glade를 쓰는 사람들은 드루이드라는 말을 보게 될 것이다.  glade는 개발자용이니까 위젯 이름을 그대로 반영하는 게 좋다.

(업데이트) 이제 GnomeDruid는 deprecated이고 GtkAssistant로 대체되어 이제 마법사라는 말조차도 못 보게 될 것 같다.

클라이언트 컨트롤과 보안

액티브엑스 보안에 관한 행정 자치부의 답변 중에서 가장 문제가 되는 부분:

○ 완전한 안전성, 보안성을 확보하기 위해서는 민원인 PC에 대한 완벽한 제어, 위변조 방지 장치 등을 갖추어 놓아야 함
○ 외국에서는 이러한 보안상의 문제가 심각하지 않으므로 민원인 PC에 대한 제어 등이 필요치 않으므로 유사사례가 있을 수 없음

외국에서 보안상의 문제가 심각하지 않아서 PC에 대한 제어가 불필요한 게 아니다.  우리와 그들의 차이점은, 아무리 머리를 굴려도 PC를 "완벽히" 제어할 방법이 없다는 걸 그 사람들은 알고 있기 때문이다.  (기술적으로 제어하기 어려우니 DMCA같은 법으로 제어하려고 하긴 하지만..)

보안 업체들은 분명히 불가능하다는 걸 잘 알고 있었을 텐데 왜 불가능하다고 말하지 못하고 현재와 같은 가짜 보안으로 눈가림을 한 것일까?  아니면 정부가 괜히 완벽하다고 오해한 걸까?

경험과 일반화

모교에서는 여름 방학 기간동안에 해외 교포 고등학생들을 초청해서 여름동안 지내게 하는 프로그램이 있었다.  그들이 한국을 떠나면서 한국에 대한 결론은 하나같았다.  "한국에는 모기가 많다."  안 그래도 여름철인데, 개천 앞에 있는 논을 갈아엎어 만든 모기 많은 학교에서 두어달을 지냈으니 그런 결론을 내릴 만도 하다.

한국 컴퓨터 사용자들이 마이크로소프트에 중독된 것은 맞지만, 이런 이유 때문은 아니다.  애플이 비교적 두각을 나타내지 못하는 이유도 가격때문만은 아니다.  자신의 어설픈 경험으로 모든 이슈의 원인을 그것으로 돌리는 말을 함부로 한다면 웃음거리가 되기 쉽다.

일과 재미

회사를 나오기 전에 누군가와의 잠깐의 대화:

CW: 재미가 없고 하고 싶은 일이 없어서요.
A씨: 일을 재미로 해요?
CW: 네!

대학에서 학과 교재로 사용했던 책이 Structure and Interpretation of Computer Programs였는데, 거기에 있는 대부분의 내용은 잊어버린지 오래이지만 아직도 기억에 남아 있는 문구가 있다.  이 책의 서문의 일부분이다.  (지금 찾아보니 서문도 아니고 그냥 앞에 나오는 말)

I think that it's extraordinarily important that we in computer science keep fun in computing. ...

적어도 그때부터 지금까지는 (많은 컴퓨터 매니아들과는 달리 난 그 시절에 컴퓨터를 처음 접했다) 그 "재미"를 찾아나가고 그 재미를 계속 간직하려고 했다.  그리고 지금까지는 아주 재미가 있었고, 꽤 성공적이었다고 생각한다.  :-)

하긴, 밥벌이에 재미가 있을 필요는 없지만 재미없는 밥벌이때문에 컴퓨팅의 재미를 잃어버리는 건 좋지 않은 일이다.

CVS에서 Subversion으로 바꾸기, 좋을까

그놈 CVS가 subversion으로 전환한 이후 얼마가 지났으나 사실 큰 장점을 못 느끼는 게 사실이다.  애초에 subversion은 cvs와 같은 모델의 vc를 만들면서 cvs의 단점을 보완하는 게 목적이었고, 사용법부터 시작해서 크게 다르지 않다.  흔히 cvs와 비교해 장점이라고 하는 것들을 살펴보면:

1. renaming, file property 따위의 versioning

안정된 프로젝트일 수록 디렉토리 이름을 바꾸는 일은 그리 많지 않다.  (과거에 회사에서 오타가 섞인 이름마저 끝내 바꾸지 못했던 기억이 있다.)

2. atomic commit/tag

CVS의 commit/tag가 atomic이 아니라고 해서 문제가 될 상황도 별로 많지 않다.  오히려 (사람이 직접 신경 쓰지 않으면 해결할 방법이 없는) 논리적인 충돌이 더 많이 발생한다.

3. lightweight branching

이 부분은 서버의 로드와 관련된 것이므로, 알기 어렵다.  분명히 장점이다.

4. diff/revert에 네트워크 연결이 필요없다

이것만은 확실히 좋다는 걸 느낀다.  cvs는 diff를 할 때마다 해당 파일의 전체 내용을 전송받는데, 유럽에 있는 gnome cvs 서버에서 이 내용을 받는 건 만만치 않은 일이다.  심심풀이 해커도 그리 느끼는데 업으로 삼는 사람들은 더더욱 좋다고 생각할 듯.


subversion은 cvs와 비교해 분명한 장점이 있으나 멀쩡히 안정적으로 잘 돌아가는 닫힌 프로젝트의 vcs를 cvs에서 svn으로 바꾸는 일은 별로 추천하지 못하겠다.  옮겨가는 데 별로 무리도 없지만 얻는 장점도 별로 없기 때문이다.  (gnome처럼 vcs 이용자가 워낙 많고 세계 여기저기에 퍼져 있는 경우라면 위의 3/4 항목으로 큰 이득을 볼 수도 있겠지만)

gst + python 팁

여러가지 방법으로 GStreamer를 사용할 수 있긴 하지만 GObject를 기반으로 한 동적인 특징은 파이썬과 상당히 어울린다.

GStreamer에서 흔히 하는 일 중의 하나가 n개의 element를 만들고 그 element를 pipeline에 추가한 다음에 줄줄이 연결하는 일인데, 사용하는  컴퓨터의 pygst가 구버전인지 add_many()는 구현되어 있지만 link_many()가 구현되어 있지 않다...  그래서 map/zip으로 해결.  (하는 김에 add_many()도 map으로)

import gst

player = gst.Pipeline('player')

elements = [gst.element_factory_make('filesrc'),
            gst.element_factory_make('mad'),
            gst.element_factory_make('gconfaudiosink')]
elements[0].set_property('location', 'fighter.mp3')

map(player.add, elements)
map(lambda (x,y): x.link(y), zip(elements[:-1], elements[1:]))

player.set_state(gst.STATE_PLAYING)

데비안 4.0 etch - 데스크탑은 그놈

우분투의 "playing advocacy" 전략이 제대로 먹혔었기 때문일까?  이제 데비안 4.0 etch에서는 Desktop environment 태스크를 설치하면 GNOME만 설치한다.  물론 tasksel로 나중에 설치한 뒤에 kde-desktop을 설치하면 되긴 하지만 설치할 때는 지원하지 않는다.

데비안 입장에서 (advocacy 전략을 통해 얻는 사용자 편의보다도) 더 큰 이유는 첫 번째 CD 안에 두 데스크탑 환경을 넣기가 불가능하다는 점이다.  그렇다고 둘 다 포기할 수는 없는 노릇.

tasks="standard, kde-desktop" 파라미터를 넘기면 KDE task를 설치하기는 하지만 첫번째 CD에 없는 관계로 CD에서 설치할 때는 곤란하다.  (DVD라면 OK)

어색한 메세지 번역을 피하는 팁 몇가지

문장 부호를 똑같이 붙이려고 하지 말아라.
- 우리말에서는 문장에 세미콜론을 쓰지 않는다.
- 원문에 쉼표가 있다고 번역문에 쉼표를 넣을 필요는 없다.  우리말로는 쉼표를 쓰지 않아도 문장이 명확한 경우가 많다.
- 영어에서는 흔히 문장 끝에 괄호를 열고 괄호를 닫은 다음 마침표를 찍는다.  하지만 우리말에서는 그렇게 쓰지 않는다.

영어 문장의 처음에 쓰인 대소문자를 그대로 따라할 필요는 없다.
- 영어에서는 첫 단어가 소문자로 쓰는 단어일 경우에도 (프로그램 이름 따위) 대문자로 만들어서 쓴다.  그대로 쓰지 않도록 신경 쓴다.

관계사가 줄줄이 붙은 문장을 한문장으로 번역하려고 순서를 여기저기 뒤집지 않는다.
- 어느정도 같은 말을 반복하더라도 여러 문장으로 쓰는 편이 낫다.  한 문장으로 쓰려고 하다가는 오히려 말 순서가 바뀌어서 핵심단어가 뒤에 가는 등 의미가 불명확해질 수가 있다.

The porn industry says HD DVD

CES 2007: HD DVD versus Blu-ray - The porn industry says HD DVD

http://www.tgdaily.com/2007/01/11/ces2007_hddvd_blu_ray/

HD-DVD가 블루레이에 승리하는 건가?  포르노는 언제나 비디오 매체의 첨단을 주도한 업계인지라...

Nexuiz - 일인칭 슈팅 게임

DDTP 번역 작업을 하는 중 우연히 Nexuiz라는 게임의 패키지 설명을 번역하게 되었다.  FPS 게임도 재미있게 했었고, 또 데비안에 들어 있는 GPL로 배포되는 게임을 안 깔아볼 이유가 없다!  (그런데 데이터 패키지 파일 하나가 무려 130메가)

딱 플레이해보면 하나부터 열까지 연상되는 게임이 "언리얼 토너먼트"였다.  분위기부터가 으슥하면서 여기저기 점프대와 워프할 수 있는 문이 보인다.  형형색색의 갑옷을 입은 미래전사들이 화면을 가르는 뿅뿅 소리를 내면서 광선으로 상대방을 가루로 만들고 다닌다.  각종 아이템으로 무기와 탄환을 먹고 체력을 회복하고 파워업을 하며 전우좌후로 여기저기 재빠르게 움직이며 상대가 보이자 마자 인정사정 보지 않고 달려들며 총부터 쏜다.

http://www.alientrap.org/nexuiz/public/2.jpg

오히려 최근 FPS의 추세는 이러한 퀘이크나 언리얼 토너먼트와 같은 게임과는 달리 사실적인 사격과 사실적인 움직임을 구현한 게임들이 주도하고 있다.  총을 한 두방만 맞아도 죽고, 총구가 흔들리고, 캐릭터나 무기에 따라 적중 확률이 달라지고, 연사보다 점사의 정확도가 높고, 총을 쏘는 자세에 따라 집탄도가 다르다.  사실적인 게 꼭 좋다기 보다는, 매니아들을 위한 게임보다는 좀 더 대중화될 수 있는 게임을 만드는 게 이익이니까. 

어쨌든 충분히 FPS를 즐길 수 있는 상당히 높은 완성도로 구현되어 있다.  멀티플레이를 위한 게임이라서 더 그럴 수도 있지만 특별히 다듬어야 할 부분이 보이지 않는다.  (하지만 괜히 싱글플레이해보려다가 꽤 높은 수준의 봇때문에 당황했다.  언리얼류에 비해서는 꽤 어렵다...) 

그나저나 이제 FPS를 할 때는 아닌가보다.  멀티플레이 해 보려고 접속하자 마자 이렇게 총도 얼마 못 쏴보고 계속 학살당하다니..  (자동 조준 기능이라도 집어 넣은 클라이언트를 쓰는 건가;;)

freedoom 센스

며칠 전에 FreeDoom을 플레이해 보게 되었다..  (둠의 엔진은 이미 오래전에 GPL로 공개되었지만 데이터인 WAD 파일은 여전히 non-free였기에 자유롭게 배포할 수 있는 데이터를 만드는 프로젝트가 FreeDoom이다.)  어차피 FreeDoom의 몬스터 동작 방식은 엔진에 코딩되어 있기 때문에 사실 맵과 그래픽만 다르고 몬스터의 동작이나 게임 방식은 똑같다.  아직 FreeDoom의 데이터는 미완성인 상태로, 아직 완성되지 않아서 치트코드를 쓰지 않고는 클리어가 불가능한 스테이지도 있고 난이도 조절이 안 된 부분도 많이 보인다.  (대체 엄폐물도 없는 좁은 통로에 Mancubus 여러마리를 놔 두면 어떻게 하라는 건지..)

Doom II를 플레이해 봤다면 마지막 보스, Icon of Sin을 기억할 것이다.  무시무시한 짐승의 모습을 하고 벽에 붙어 있으면서 마구 재생성되는 강력한 몬스터들.  유일한 클리어 방법은 로켓을 exposed brain에 정확히 꽃아 넣는 것이었다.  처음엔 타이밍을 맞추기 상당히 어려웠지만 나중에 가서는 재미를 위해 일부러 몬스터가 몇마리 생성될 때까지 기다리곤 했다.  :D  (재빠르게 두 번 꽃아 넣으면 끝나기 때문에 난이도를 높여봤자 의미가 없었다.)  재미있는 점은 둠의 IDCLIP 치트코드를 이용해 벽을 뚫고 Icon of Sin의 내부를 들여다 보면, 괴상한 얼굴이 꼬챙이에 꽃혀 있는 걸 보게 된다.  그 얼굴의 주인공은 John Romero로..  John Carmack과 함께 ID 소프트웨어를 만들었던 둠의 개발자 중의 하나이다.  (Icon of Sin이 처음 등장할 때 중얼거리는 이상한 소리는 "To win the game, you must kill me, John Romero!"라는 말을 거꾸로 한 것이다.)

FreeDoom도 몬스터 체계는 Doom과 똑같기 때문에..  30레벨에 가서 Icon of Sin을 만날 수 있었다.  Doom II와는 달리 Icon of Sin을 만나는 과정이 상당히 험난했다..  하지만 IDDQD / IDKFA 치트키를 이용해서...

그러면 과연 저 안에는 누가 있을까?  John Romero를 그려 넣지는 못했을 텐데...

이런 엉뚱한 놈들..  -_- 

(어쩌면 Icon of Sin 얼굴이 gnu같기도?)

표준과 현실 모두 만족하기

(1)

RFC822에서 이메일 주소의 형식을 보면 다음과 같다.

addr-spec   =  local-part "@" domain        ; global address
local-part  =  word *("." word)                ; uninterpreted
                                                       ; case-preserved

local-part는 대소문자를 구별한다.  하지만 예전에 하이텔이 PC통신 회원들을 상대로 이메일 서비스를 개시할 때..  대소문자만 달라서 중복된 아이디는 구별되게 바꾸도록 조치했다.  학교 동기 중의 하나가 그 대상이었는데..  하이텔의 변명은 "메일 주소의 인터넷 표준을 따르기 위해"였다.  당연히 하이텔이 틀렸고, 복잡한 싸움 끝에 담당자가 "표준때문은 아니다"라고 인정하긴 했지만 아이디를 바꿀 수밖에 없었다.  :D  

진짜 이유는 이메일 서버들이 관행적으로 대소문자를 구별하지 않았기 때문이다.  지금도 아마 모든 어떤 메일 서버에서도 이메일 주소의 대소문자를 바꿔써서 보냈을 때 아마 같은 사람에게 도착할 것이다.  (이메일 주소마다 1개의 아이디만 만들 수 있는 웹사이트중에 어떤 경우는 이 점을 이용하면 아이디를 여러 개 만들 수도 있다.)

(2)

Evolution이 보낸 메일 제목이 MS Outlook/Outlook Express에서 깨져 나왔다.  (최근 버전의 Outlook에서는 올바르게 처리한다.)  그 이유는 Evolution이 메일 제목을 무조건 UTF-8로 RFC2047 인코딩해 버리기 때문이었는데, Outlook이 본문이 EUC-KR 인코딩되고 제목이 UTF-8 인코딩된 경우를 제대로 처리하지 못했다. 

결국 버그는 거부당했는데, Outlook의 버그일 뿐인데 왜 신경 써야 되냐는 얘기였다.  (사실 구조상 호환성을 깨지 않고는 고치기도 매우 어려웠기 때문에 좋은 핑계가 되었다.)

(3)

mediawiki에서 옛한글을 입력하면 유니코드에서는 자모로 "ㅈㅕㅇ" 세 개 자모를 입력해야 하는데 (ㅇ이 꼭지이응이라고 가정하면), mediawiki는 글을 입력하는 순간 이걸 "져ㅇ"과 같이 normalize해 버린다.  normalize해서 "음절+종성자모"로 만드는 게 잘못된 건 아니고 분명히 올바른 코드이지만, 문제는 옛한글을 지원하는 트루타입 글꼴이라면 보통 "ㅈㅕㅇ"을 제대로 음절로 표시하는 반면 "져ㅇ"은 제대로 표시하지 못한다.

mediawiki의 잘못일까?  유니코드 표준을 충분히 구현하지 않은 세상의 한글 글꼴들 잘못일까?


표준은 중요하지만, 표준보다 더 많은 것을 고려해야 할 때도 있고, 표준을 어기는 소프트웨어들을 욕만 할 수는 없고 맞춰야 할 때도 있다..  표준을 어기지 않으면서 맞추는 방법을 찾아야 겠지만?

iceweasel 번역

iceweasel을 실행하는 중에,

fork때문에 의도하지 않은 상황이 발생.  과연 버그일까.

Debian/Ubuntu 사용자는 popular-contest를 써 주세요

프로그래밍을 모르는, 혹은 프로그래밍하기 귀찮은 (...) 사용자가 프리소프트웨어 프로젝트에 기여할 만한 일은 여러가지가 있습니다..  하지만 그 여러가지도 (버그리포트, 번역, 문서, 커뮤니티, ...) 생소한 대부분의 사람들에게는 귀찮기 짝이 없죠.  그래서 이 글을 끝까지 다 보기 전에 끝낼 수 있는, 별로 귀찮지 않은 한 가지 간단한 방법을 떠올렸습니다.  개인정보를 팔 통계 작업에 참여해 주시면 상당한 도움이 됩니다.

데비안/우분투 사용자라면 popularity-contest를 설치하시고, 혹시 이미 설치되어 있다면dpkg-reconfigure 명령으로 이 기능을 사용하도록 설정하십시오.  개인정보를 파는 건 농담이고, popular-contest가 보내는 하드웨어 정보는 무슨 아키텍쳐를 사용하느냐 정도뿐이고 (사실 lspci -v 결과같은 것 좀 수집해 봤으면 좋겠는데), 시스템에 무슨 꾸러미(패키지)가 깔려 있나의 정보만 보냅니다. 

명시적으로 설정해야만 정보를 보내기 때문에 (당연히 사용자의 명백한 동의가 있어야 되겠죠) 전체 사용자 규모에 비하면 현재 2만명 정도의 통계는 별로 충분한 숫자가 아닙니다.  위에 스크린샷에 쓰여있는 것처럼 CD 만들 때 우선순위를 결정하는 용도에도 쓰이고, 부족한 점을 개선하는 데에도 중요한 자료가 됩니다.  예를 들어 http://popcon.debian.org/unknown/by_vote 여기를 보면 데비안에 없는 아마도 non-free인 꾸러미를 뭘 깔았냐를 볼 수 있고 데비안에 무엇을 개선해야 하는지 참고 자료가 됩니다.  (멀티미디어 툴들, JDK, skype, opera, ...)

데비안의 경우에는 http://popcon.debian.org, 우분투의 경우에는 http://popcon.ubuntu.com 사이트에서 정보를 볼 수 있습니다.

BSD 사용자라면 BSDstats 프로젝트에 참여할 수 있습니다.  (http://openlook.org/blog/1116)