현재 유닉스 스타일 파일시스템의 의미는

리눅스에서 많이 사용하고 있는 File Hierachy Standard 는 전통적으로 유닉스에서 사용되던 표준 파일 시스템을 명백히 표준으로 정의한 것이다. 유닉스나 리눅스 사용자라면 익숙하다 못해 친근하기까지 한 /lib, /bin, /sbin, /usr/bin, /usr/share, /usr/lib 따위의 구조는 영원히 없어지지 않는 성역이라고 생각하기 쉽지만, 이제 근본적으로 바뀔 때도 되지 않았을까? 과거의 유닉스 플랫폼의 사정이 오늘날에도 적용이 될까?

유닉스 파일 시스템의 구조는 몇 가지 목적을 가지고 만들어졌다.

• 부팅과 최소한의 관리에 필요한 파일 (/), 시스템 설치 파일 (/usr), 사용자 설치 파일 (/usr/local) 구분으로 공유 가능
  
• 아키텍처 의존 파일과 (/usr/lib) 독립 파일을 (/usr/share) 구분해서 독립 파일을 여러 아키텍쳐 컴퓨터 사이에 네트워크로 공유 가능
• 읽기 전용 파일시스템, 시스템 설정, 데이터 파일 시스템 구분 (/usr, /etc, /var 구분)

정말 공유하는 사람이 있나요?

큰 목적은 "파일 시스템의 공유 가능"이다. 부팅에 필요한 파일은 컴퓨터마다 필요하지만 /usr 아래의 대부분은 공유할 수 있다. 아키텍처가 다른 컴퓨터 사이에는 일부 파일은 공유할 수 없지만 /usr/share 따위는 공유할 수 있다. 오호라! 진짜? 요즘 세상에 이렇게 공유하는 곳이 있을까?

거의 10년 전 학교의 컴퓨터 실에는 이런 식으로 설정된 몇 대의 스팍 서버가 있었다. 하지만 이러한 멋진 구조 덕분에 최악의 안정성을 자랑했다. single point of failure, 한 머신이 죽으면 그 파일 시스템을 공유하는 모든 서버가 동작 불가능이었다. 실제로 그 서버 구성의 최대 장점은 홈 디렉토리의 공유였지 /usr 따위의 공유가 아니었다. /usr의 공유는 /usr 파일 시스템의 크기가 크고, 스토리지의 가격이 비쌀 때 가치가 있지만 용량도 커지고 가격도 내려간 지금의 하드디스크에서 /usr 파일 시스템이 공유할 만큼의 가치를 지니지 않는다.

그리고, 오늘날의 실정을 여러 모로 보면 리눅스 파일 시스템에서 /usr를 공유할 수 있다는 말은 거짓말이다. /usr/include를 보면 각 아키텍처에 의존하는 값이 잔뜩 들어 있는 헤더가 가득하고, 패키징 시스템은 /usr/share와 /usr/lib 에 동시에 파일을 설치한다.

정말 /usr 파일 시스템을 읽기 전용으로 별도 파일 시스템에 마운트해서 여러 컴퓨터 사이에 같은 아키텍처인지 아닌지에 따라 /usr/share와 /usr/lib을 구분해서 공유하는 곳이 있기는 할까? 아무리 네트워크 파일 시스템을 널리 사용하는 곳도 홈 디렉토리 공유나 대용량 스토리지 구현을 위해 사용하지 "비교적 작은" 크기의 /usr 디렉토리를 읽기 전용으로 마운트하려고 사용하는 곳은 본 적이 없다. 10년 전의 그 학교 컴퓨터 실에서도 아키텍처별로 구분하지는 않았다.

과거의 잔재

한편 /usr/X11R6 및 /usr/games라는 구조가 남아 있는데  /usr/X11R6는 X11 및 CDE/XView 따위가 굉장히 커다란 소프트웨어였던 시절에나 의미있는 구분이었다. 이제 X.org 프로젝트는 이 구조를 따르지 않는다. (/usr/X11R6/bin은 /usr/bin으로 가는 심볼릭 링크이다.)  /usr/games, /var/games같은 경우에는 BSD의 잔재인데 FHS 문서에 따르면:

The separation allows local control of backup strategies, permissions, and disk usage, as well as allowing inter-host sharing and reducing clutter in /var/lib

백업 방식을 다르게 하기 위해서, 권한을 다르게 하기 위해서, 컴퓨터 사이에 점수 따위를 공유하기 위해서, /var/lib 크기를 줄이기 위해서라고 되어 있다. 이 역시 오늘날의 실정과 맞지 않는다.

바꿀 필요가 없으니까?

굳이 전통적으로 잘 써 왔고 각종 툴이 잘 지원하는 지금의 파일 시스템 구조를 바꿀 필요가 있을까?

일단 현재의 문제는, 소프트웨어 바이너리 패키지의 유연성이 떨어진다. 현재 조금 복잡도가 높은 리눅스 소프트웨어들은 빌드타임에 데이터가 들어 있는 디렉터리가 보통 하드 코딩되어 있다. RPM 패키지의 경우 /usr, /usr/local을 선택할 수 있는 relocatable 패키지를 만들 수 있는 기능이 있지만 이렇게 경로를 하드 코딩하는 애플리케이션들은 relocatable하게 만들기 어렵다. 현재의 파일 시스템에서는 바이너리 패키지만으로 같은 애플리케이션의 여러 버전을 동시에 설치하거나 사용자에 따라 다른 애플리케이션을 설치한다거나 하는 유연성이 없다.

애플리케이션별로 별도의 경로로 설치하면 명령어 실행 경로라든지 ($PATH), 맨페이지, 폰트처럼 한 프로그램이 사용하는 데이터를 여러 패키지에서 설치하는 경우에 문제가 생기지만, 해결 방법은 있다. 한 디렉토리 안에 파일을 몰아 넣지 않더라도 파일시스템의 기능을 통해 여러 경로의 내용들을 한 곳으로 자동으로 합치는 기능이 있다. (이름이 생각이 안 나서 검색 불가...)

네이트온 패키지

얼마간의 고민 끝에 pidgin-nateon을 패키징해서 데비안 메인에 업로드했다.

http://packages.debian.org/sid/pidgin-nateon

현재 리눅스에서 쓸 수 있는 네이트온 클라이언트는 세 가지가 있다. 공식 네이트온 (knateon), pidgin 플러그인, 그리고 자바로 만든 자테온. 그런데 세 프로젝트들 모두 패키징을 검토해 보았으나 모두 빌드 구조나 릴리즈 방식 따위가 부족한 점이 많아서 아쉽다.

여행자를 위한 데비안 미러 사이트

여행을 다녀서 빠른 데비안 미러 설정에 그때그때 고민된다면 이제 cdn.debian.net을 사용하면 된다.

$ host cdn.debian.net
cdn.debian.net is an alias for deb.cdn.araki.net.
deb.cdn.araki.net has address 143.248.234.110
$

geoip 결과에 따라 가까이 있는 미러값을 리턴해 준다. 위의 값은 ftp.kr.debian.org로 되어 있는 카이스트 미러.

카이스트 네트워크 뒤집히는 일이 많다는 거야 학교 다닐 때에도 많이 겪은 일이긴 하지만, 현재 카이스트 미러는 주5일제라는 우스개소리를 할 정도로 너무 사고가 많다. 이제 제발 휴일에 죽어버리는 일 좀 그만 일어났으면...

dpkg 1.10.25 (2004년)

dpkg (1.10.25) unstable; urgency=low

  The "你他媽的天下所有的人都該死" Release.

  This release is to correct the mangled Simplified Chinese translation
  included in 1.10.24 caused by rebellion of the translator's mail client.

  * Updated Translations (Christian Perrier):
    - Dutch (Bart Cornelis).  Closes: #278700.
    - Polish (Bartosz Fenski).  Closes: #280406.
    - Simplified Chinese (Tchaikov, Carlos Liu).  Closes: #278676.

 -- Scott James Remnant <scott@ netsplit.com>  Thu, 11 Nov 2004 20:06:57 +0000

데비안 패키지의 VCS 사용

오래됐지만, 예전에 썼던 것처럼 모든 패키지를 소스 컨트롤에 올렸다.

그와 함께 한국어 관련 패키지들을 l10n-korean 프로젝트의 git repository에 올려놓았다. (l10n-korean/*.git 페이지)  희망사항은 한국어 관련 패키지들의 공동 관리 체제로 가는 것인데..  충분히 참여할 사람이 있을 지는 아직 미지수이다. (의향이 있으면 alioth의 l10n-korean 프로젝트에 신청하시길.)

이제 debcheckout으로 패키지의 소스 컨트롤 시스템에서 직접 받아올 수 있다는 거!

duncan:~/debian/l10n-korean/tmp$ debcheckout libhangul
declared git repository at git://git.debian.org/git/l10n-korean/libhangul.git
git clone git://git.debian.org/git/l10n-korean/libhangul.git libhangul ...
Initialized empty Git repository in /home/cwryu/debian/l10n-korean/tmp/libhangul/.git/
remote: Generating pack...
remote: Done counting 156 objects.
remote: Deltifying 156 objects...
remote:
Indexing 156 objects...
remote: Total 156 (delta 70), reused 50 (delta 9)
 100% (156/156) done
Resolving 70 deltas...
 100% (70/70) done
duncan:~/debian/l10n-korean/tmp$ ls libhangul/
AUTHORS      Makefile.in  compat     configure*    hangul/        test/
COPYING      NEWS      compile*     configure.ac  install-sh*
ChangeLog    README      config.guess*  data/           libhangul.pc.in
INSTALL      aclocal.m4   config.h.in     debian/       ltmain.sh
Makefile.am  bindings/      config.sub*     depcomp*      missing*

아시나요 - 데비안 미러

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

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

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한다.

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

...
...

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

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

데비안 문제 (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 등 데비안의 소스컨트롤에 등록할 예정이다.  그리고 가능하다면 원하는 모든 사람들에게 커미트 권한과 업로드 권한을 부여한다.  이 정도가 현재 할 수 있는 일이다.  (내 하드 디스크에서 계속 소스 관리하기가 피곤해서이기도 하고...)

데비안 문제 (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 마스터들을 충원하기도 쉽지 않은 일이다.  내 생각은 일단 없애 보자는 것.

데비안 문제 (1) - unstable

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

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

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

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

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

데비안 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)

Nexuiz - 일인칭 슈팅 게임

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

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

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

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

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

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

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)