데비안 문제 (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, 업체, 사용자가 모두 다른 방향을 바라보고 있는 게 아닐까?


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