배포판 제작하기, Part 1
Gentoo Linux 배포판의 탄생
난이도 : 초급
Daniel Robbins, CEO, Gentoo Technologies, Inc.
2000 년 11 월 01 일
Linux를 경험해본 적이 있다면 각자 나름대로의 이야기 거리를 가지고 있을 것이다. 이 글은 Daniel Robbins의 Linux 이야기이다. 세 개의 시리즈 중 첫번째 순서에서는 필자가 Stampede Linux의 개발자가 된 경위와 Stampede를 떠나 Enoch라는 자신의 배포판을 제작하기 시작한 이유를 설명한다.
Linux 와 나
Linux 라는 "괴짜"를 다루다 보면, Linux가 그 이름이 가지는 의미 이상으로 더 훌륭하고 강력하며 매력적인 부분이 있다는 것을 알 수 있을 것이다. 나는 이 것을 New Mexico 대학에서 시스템 관리자로 일하고 있을 때 체험하였다. 내가 맡고 있는NT 서버는 원활히 가동되고 있었고 따라서 나에겐 여유 시간이 있었다. 그래서 펜티엄 166 서버 박스에 Debian (Linux 배포판에 포함됨)을 설치하고 독학하기 시작했다. 배우고, 배우고 또 배웠다. 그러다가 헤어나지 못할 정도였다.
처음엔 Linux에 대한 기본적인 모든 것을 학습하였다: 이것저것 다루어 보고, 백업하고, Samba 실행하는 방법 등도 학습하였다. 그리고 qmail과 Apache를 설치하고 Python과 shell프로그래밍을 배웠다. 부서의 Intranet을 구축하고, 집에 Linux를 설치했으며 다른 배포판을 시도하기 시작했다. 결국 Stampede Linux로 결정했다. 이 과정이 어떻게 진행되는지 알 것이다. 처음에는 Linux의 기초를 파악하기 위하여 애쓴다. 어느 정도 사용에 익숙해지면, 배워가면서 자신의 Linux를 만들게 된다. Linux는 숨길 것이 없기 때문에, Linux를 기동할 수 있는 테크놀로지와 툴을 익힐 수 있다.
Linux의 잠재성
Linux는 내가 기존에 알지 못했던 무엇인가를 제공했다. 그 마력을 단어로 표현하면 바로 잠재성이라 하고 싶다: 상황을 변화시키고, 개선하고, 결정하며, 또한 파괴시킬 수도 있는 바로 그 잠재성이다. 새로운 커널 버전으로 업그레이드하면서, 눈앞에서 Linux가 향상되고 스스로 변형하는 것을 거의 매일 발견한다. 나는 그 과정 자체를 따라갔다! 이미 나는 변형의 한 부분이 되어 있었다. 유쾌했다.
여러분도 나와 같은 경우라면, Linux와 오픈 소스에 관심을 갖기전에는 여러분이 원하던 일을 실현시켜줄 것 같은 차세대 운영체제를 제공하는 Redmond 와 Cupertino와 같은 대그룹들을 주목했을 것이다. 그러나 그 꿈은 전혀 실현되지 않았다. 그리고 기다리는 동안, Linux가 나타났다. 수정되어야 할 부분이 많지만, Linux는 해커들이 다음의 거물을 기다리는 동안 개선 가능한 것을 제공했다. 그리고 어느날 잠에서 깨었을 때, Linux는 다음의 거물이 되어 있었다.
Linux와 사람.
다음으로 내가 배운 것은 Linux가 사람과 비슷하다는 것이다. 신선하지 않은가? Linux는 소스 코드의 묶음이 아니다. Linux는 커뮤니티다. 질문에 관련 해답을 찾기 위해 이 커뮤니티에 의지하고, 시간과 전문성을 할애하여 다른 사람들을 돕게 되면 커뮤니티의 일부분이 된다.
IRC(Internet relay chat)는 사람들을 만나고 어마어마한 시간이 허비되는 대단한 장소다. irc.openprojects.net의 #stampede 채널은 나의 공식적인 아지트가 되었다. 거기에서 Linux에 관한 질문을 했다. 그곳에서 또한 나는 처음으로 다른 사람들을 도와주었다. #stampede는 이제 막 배포판을 설치한 초보자들을 도울 수 있는 Linux 사용자가 매우 부족했다. IRC에서 대개 그렇듯이, 경험 많은 Stampede 사람들이 newbie관련 질문에 답변하려는 열정을 잃어버렸다. 하지만 나는 사실 질문에 대한 해답을 가지고 있었고, 돕는 일을 중지할 수 없었다! 이렇게 하여 Stampede에 참여하게 되었다. 나는 질문에 답변하기 좋아하는 그런 부류였다. 내가 이타적인 사람이라서 그런 것이 아니라 Linux 관련 지식 전문가가 되고 싶었기 때문이다.
참여
오픈 소스 프로젝트에 참여하는 방법에 대해 질문하면, 비록 기초적인 Linux 관련 질문에 대한 것이라도 사용자가 도움을 줄 수 있는 장소를 먼저 찾으라고 말한다. 타인을 돕고자 하는 진실한 욕구가 Linux 커뮤니티에 참여할 수 있는 훌륭한 입장권이다. 이러한 감정이 Linux를 포함한 모든 오픈 소스 개발의 중심이기 때문이다. 적어도 그렇게 되어야 한다.
시간이 지날 수록 더 많은 해박한 지식을 가진 사용자를 만날 것이다. 여러분은 그들에게서 배울 것이다. 마치 초보자들이 여러분에게 계속 배우는 것 처럼 말이다. 또한 경험이 많아짐에 따라, 새로운 방식으로 도울 기회들을 접할 것이다. 접할 지도 모르는 프로젝트 개발자들이, 어떤 것을 제안하거나 그들 스스로 도움을 요청할 수도 있다. 개발 팀의 일원이 되도록 여러분을 초대까지 할 수도 있다. 다른 사람들을 돕는데 집중한다면, 그들은 어리석게도 여러분을 지나칠 것이다. 많은 사람들을 계속 돕고 있다면, 커뮤니티에서 분명히 눈에 띨 것이다. 바로 이것이 Stampede와 나에게 발생한 일이다.
점차적으로 Stampede 개발에 깊숙하게 참여하게 되었다. 이윽고 공식적인 Stampede 개발자가 되었다. 한 스키광의 찬성을 얻어 (Matt Wood, Stampede의 리더), Stampede의 초기 .slp 패키징 포맷의 새로운 버전 발표를 준비하기 시작했다. 당시 .slp 패키지 포맷은 끝에 붙은 고정 길이의 풋터(fixed-length footer)를 가진 .tar.bz2 아카이브로 구성되었는데, 이 풋터(footer)는 패키지의 저자, 내용 설명, 패키지의 창안자 등에 관한 정보를 제공한다. 이 접근법은 두 가지의 중요한 문제를 가지고 있다. 하나는 필드 길이의 고정이고 다른 하나는 작은 풋터의 사이즈와 포맷에 내장될 확장성이 없다는 것이다 (.slp 포맷에 필드 추가할 수 있는 방법이 없다). 분명히 철저한 정비가 필요했다.
Stampede 선임 개발자들과 일하면서, 이 문제를 해결할 수 있는 방법에 대한 제안서를 작성했다. 그때 Python으로 프로토타입 툴(prototype tools)을 코딩했다. 새로운 포맷은(코드네임 slpv6) Amiga의 IFF 파일 포맷과 어느 정도 유사했다. 이 차세대 .slp 포맷은 232개의 필드, 232개의 필드 카테고리, 그리고 232바이트의 필드 데이터 최대길이를 허용했다. 포맷은 막강한 확장성 뿐만 아니라, 또한 평문(plain text)보다 콤팩트하고 파싱하기가 쉬웠다. 텍스트와 이진 데이터 모두 포맷에 저장이 가능하므로 향후 많은 가능성을 가지고 있었다. 이 차세대 동적 헤더를 아카이브 파일의 끝에 부착하는 아이디어인데, 이로써 수 년간 Stampede 사용자들이 쓸 수 있으며 동시에 유닉스 표준 아카이브 포맷과도 호환성을 유지하는 차세대 .slp 포맷이 나온 것이다.
사람들과의 관계
slpv6의 개발은 순조로웠고 모든 선임 개발자들은 나의 진보를 기뻐했다. 그러나 불행하게도, Stampede 하급 개발자 두 사람이 slpv6 프로젝트를 통제하려고 했다. 그들은 나의 추진 의도에 반대하였고, 오랫동안 새로운 slpv6 시스템을 비난하였다. 몇 시간 동안 열띤 개발 토론에서 그들의 공격을 방어했지만, 어떤 해결점을 찾지 못했다. 본능적으로 논쟁하기를 좋아하고, 그들의 의도대로 진행될 때까지 만족하지 못한다는 것도 발견하였다. 다행스럽게, 나의 프로젝트가 Stampede 선임 개발자들의 승인을 얻었다. 그러나 이러한 토론에 신물이 났고, Stampede 개발을 무미건조하게 만들었다. 윽!
고급 개발자들과 채팅하기 위해서 #stampede 채널을 자주 방문해야 했기 때문에, 그 개발자들을 배제시킬 수 없었다. 내가 그 채널에 있을 때마다, 그들은 곧 전투적인 태세로 나의 일을 폄하하려 했다. 사실상 선임 개발자들 앞에서 나의 작업을 모욕할 절호의 기회인 개발회의 소집을 요구하는 식의 정당하지 못한 수법들을 사용했다. 그들은 또한 Stampede의 통제권을 장악하기 위해 투표를 요구하기도 했다. 물론 그들의 의견에 동의하는 사람들이 많이 있다고 판단될 때만 투표를 요구했다. 이런 과정을 겪으면서 나는 slpv6 개발 작업을 계속했다. 말할 필요도 없이 선임 개발자들은 나의 작업을 인정하여 계속 개발하기를 원했다. (그들의 지지가 없었다면 나는 끝까지 견디지 못했을 것이다).
"괴물(freak)" 이해하기
그 두 개발자들은 "괴짜" 라고 부르고 싶은 개발자 범주에 속한다. 비록 그들이 나의 개발작업을 아주 재미없게 만들었지만, 나 또한 그들을 다루면서 많은 것을 배웠다. 여기에서 여러분에게 괴짜 개발자에 관한 일종의 포괄적인 개요를 제공하고 싶다: 괴짜들의 자질, 그들의 수법, 그리고 개발 프로젝트의 리더인 여러분이 그들과 대결하여 가능하면 많은 노력을 들이지 않고 그들의 마음을 바꾸게 하는 방법.
감정적인 상처를 피하기 위하여, 하나의 전제조건이 필요한데 그것은 지조이다. 정중하지만 단호한 태도로 괴물들을 맞설 수 없다면, 희망이 없다. 괴물들의 목적은 가능한 한 많이 여러분의 프로젝트를 통제하여, 자신이 강력하다고 느끼는 것이다. 이렇게 되기 위하여 괴물들은 몇 가지 수법을 사용할 것이다. 첫째로 그들은 프로젝트와 프로젝트를 수행하는 개발자에 대하여 불공평하게 비평하거나 심하게 불평하기 시작한다. 그때 그들은 어떤 건설적인 대안 제시는 하지 않는다. 그들은 또한 그들이 프로젝트 메니저로 승진되지 않는다면, 그 프로젝트를 도우려고 하지 않는다. 그들의 목적은 그들의 눈에만 보이는 문제들을 그들이 해결할 수 있도록, 여러분의 신임을 얻어 가능한 한 많은 권위를 얻으려는 것이다.
비평과 불평이 효과가 없다면, 그들은 개발자 회의를 요구한다. 이 회의는 여러분의 개발팀을 시험하고 두 패로 나누는 그들의 계획이다. 그들 편으로 충분히 많은 사람들을 섭외 했다고 판단될 때 선거를 요구한다. 당연히 이길 게임이다. 그들이 선거에서 지거나 제압당하면, 다음주의 또 다른 개발자회의를 강행하는데, 여기에서 그들은 다시 여러분의 개발팀을 분열시키려고 한다. 그들은 이러한 과정을 끊임없이 되풀이할 것이다.
개발자회의 접근법이 여의치 않으면, 그들은 개혁가로 변한다. 이 역할을 채택하여 그들은 강압적이고 불공정한 경영 의사결정 과정을 "민주적인"(=그들이 쉽게 좌지우지 할 수 있는) 것으로 변경하는 합리화를 시도한다. 이러한 합리화는 종종 개발자중의 다수가 원하는 것은 무엇이든지 해야 한다는 확신을 갖도록 한다. 그때 여러분은 더 이상 개발자회의 투표를 뒤엎을 수 없기 때문에 괴짜들은 이 방식을 사랑한다. 이런 방식이 허용되면, 근본적으로 Lexus의 열쇠를 괴짜들에게 내준 것이다.
다른 접근법으로, 괴물들은 창조적인 개발자를 내몰 것이다. 괴물들이 프로젝트의 권력구조를 개혁하려고 강력하게 시도함에 따라, 그들은 전체 팀을 광란의 상태로 몰아넣을 것이다. 만약 그들의 노력이 실패한다면, 그들은 결점이 있는 사람들을 가능한 많이 불러 모아 프로젝트에서 분리시키려고 할 것이다.
괴물들 다루기
이러한 녀석들은 꽤 쉽게 구별된다. 그들은 코드를 작성하지 않는 자들이다(하려고 하지도 않는다). 그대신 보다 중요한 것에 대하여 이야기하며 시간을 보낸다. 알다시피 관리상의 이슈들이다. 프로젝트의 리더라면, 그들을 꽤 쉽게 다룰 수 있다. 작업 코드(working code)를 만들지 않으면 어떠한 제안도 고려하지 않겠다고 그들에게 말하라. 그렇지 않으면 그들에게 (건설적인)비평의 기회를 주기 전에, 현재의 프로젝트에 건설적으로 협조하라고 주장하라. 이것은 현재의 프로젝트 메니저에게 복종하는 것을 함축하고 있다. 그들이 약간의 괜찮은 코드를 작성하거나 보다 협조적으로 된다면, 훌륭하다. 그렇지 않다면, 떠나라고 말하라. 그들은 프로젝트를 떠나거나(여러분이 그들을 충분히 오래 무시한다면), 또는 코드를 작성하고, 대개는 좀더 즐거워하게 될 것이다.
애석하게도 Stampede 선임 개발자들은 괴물 관리에 책임을 지지 않았다. 달리 말하면, 그들은 이 두 녀석들이 나를(그리고 다른 사람들을) 끝없이 괴롭히도록 허용했다. 선임 개발자들은 항상 나의 개발작업에 호의를 가졌지만, 이 녀석들을 다스리려고 노력하지는 않았다. 그래서 어느날 나는 이 두 괴물을 참고 지내야 하는 것보다는 내 자신의 배포판을 만드는 것이 더 편할 것이라고 결심했다. 나는Stampede 개발에서 물러나 자체 배포판을 만들 계획을 세우기 시작했다.
두 저급 개발자 때문에 프로젝트를 그만둔 것이 약간 억울하지만, 그들이 사실상 관리되지 않는다는 사실은 그 프로젝트의 심각한 관리상의 문제를 나타내는 것이다. 고급 개발자들이 Stampede 개발 노력은 즐겁고 보람을 보장할 수 없거나 또는 보장하려 하지 않는다면, 그때는 그곳에 있기를 원하지 않는 것이다.
다시 시작하기
떠나고 나니 안심이 될 수 있었다. 마침내 일이 조용해졌다. 이제 배포판의 성격 및 Linux 배포판으로써 어떤 공헌을 할 지를 결정할 때이다. Stampede의 매력은 그것의 가공되지않은 성능이었다(Stampede가 실험적인 팬티엄 최적화 pgcc 컴파일러를 사용한 덕택에). 그래서 성능에 가장 중점을 두기로 결정했다. CPU의 활용을 최소화하는 것에 더하여, 부풀리기(bloat)도 최소화하고 싶었다. 많은 배포판들이(특히 대중적인 수축 포장된 것들) 디폴트로 많은 데몬을 띄움으로써, xterm을 오픈하면 RAM이 거의 남지 않게 된다. 나는 배포판이 가벼우면서도 일반적인 기능을 유지할 수 있기를 원했고, 하드웨어의 성능을 최대화하는데 중점을 두었다. 나는 전체론적인 접근법을 취하여 모든 각도에서 성능 문제에 달라붙기로 결정했다.
그러나 자료가 심각할 정도로 부족했는데 그 이유는 개발자가 나 한 사람뿐 이었기 때문이다! 맨땅에서 나 혼자 힘으로 Caldera 또는 RedHat에 버금가는 어떤 것을 창조해낼 수 있을까? 답은 자동화였다. 모든 것을 자동화하는 스크립트를 작성해야 했고, 그래서 시간이 걸리는, 반복적인 작업을 최소화할 것이었다. 결국 이것이 컴퓨터가 제일 잘하는 일이 아닌가?
나는 필요한 자동화를 위해서 단순한 스크립트 작성으로 충분하지 않으리라는 것을 즉시 발견하였다. Linux 배포판을 처음부터 구성하여 만들어 내는 완전한 시스템을 설계할 필요가 있었다. 나는 시험적으로 그것을 ebuild 시스템이라고 하고 작업을 시작했다. ebuild 시스템은, 소스의 분해(unpacking)와 패치(patching)부터 컴파일, 설치, 그리고 패키징(packaging)까지 모든 것을 자동화하면서, 모든 배포판 바이너리를 자동적으로 생성할 수 있을 것이다. 기본적인 ebuild의 프로토타입이 작동하는 것을 확인한 후, Linux 배포판의 핵심적인 구성 요소들의(gcc, glibc, binutils, util-linux, 그리고 friends같은) ebuild 스크립트를 생성하기 시작했다. 내가 초기설정 스크립트를 다시 설계하고(이전에 설계한 Stampede 초기설정 스크립트를 기본으로 하여) 새로 만든 모든 패키지를 시험하고 설치함에 따라, 나의 Stampede 개발 박스는 점차적으로 나 자신의 시스템으로 되어갔다.
몇 달 후 완전한, 스스로 주인이 된 Linux 배포판을 가지게 되었다. 그것을 Enoch이라 명명하고, 만족의 미소를 지었다. 다음에는 Enoch이 어떻게 Gentoo Linux가 되었는지 그리고 도중에서 만난 많은 새로운 도전에 대해서 이야기 하겠다.
배포판 제작하기, Part 2
Enoch에서 Gentoo로
난이도 : 초급
Daniel Robbins, CEO, Gentoo Technologies, Inc.)
2000 년 10 월 01 일
첫번째 시리즈 에서는 필자가 어떻게 Stampede Linux 개발자가 되었으며 결국 왜 Stampede를 떠나 Enoch Linux배포판을 시작하였는지 말해주었다. 이 글에서 그는 Enoch 개발팀이 불꽃같이 빠른 컴파일러를 발견한 후에 일어난 이상한 사건들을 털어놓는다.
Enoch으로 향한 첫 단계
이전의 글에서, Stampede 개발팀과 겪었던 일과 떠난 이유에 대해서 말했다. 이 쓸데없이 참견하는 구경꾼들의 간섭때문에, Stampede 개발을 계속하기 보다는 나 자신의 Linux 배포판을 만드는 것이 더 쉬우리라고 판단했다. 다행인 것은 Stampede 개발을 통하여 많은 경험을 축적했다는 것이다. Stampede 패키지를 관리했고, 초기설정 스크립트를 설계했으며, 그리고 slpv6(차세대 패키지 관리 프로젝트)를 이끌었다.
작업하기 시작한 코드네임 Enoch 배포판은 패키지 생성과 업그레이드 프로세스를 완전히 자동화하기 때문에 엄청나게 빠른 것이었다. 이것은 배포판 제작에 있어서 대부분을 차지하는 것이라고 인정하고 싶은데, 나는 one-member 팀이었고, 나의 개발용 머신이 나를 위해 자동으로 해 줄 수 있는 반복적인 일을 내가 시간을 소비하면서 할 수는 없었기 때문이다. 그리고 나는 완전한 배포판을 처음부터 구성하는 방향으로 설계하고 있었기 때문에(RedHat같은 배포판에 부수적인 변형을 하기 보다는), 힘에 겨웠고 자유시간을 모두 끌어 모아야 했다.
기본적인 Enoch 시스템을 시동하고 실행한 후, 나는irc.openprojects.net로 돌아가 #enoch라는 나 자신의 채널을 시작했다. 여기에서 점차적으로 약 열명의 팀을 모았다. 초기시절 우리는 모두 IRC(Internet Relay Chat)에서 살았고 여분의 시간에 배포판 작업을 했다. 우리가 공동으로 협동하여, 새로운 버그를 찾아내고 픽스(fix) 하면서, 잘해냄에 따라 Enoch는 나날이 보다 기능적이고 전문화되어 갔다.
첫번째 장애물
어느날, Enoch은 첫번째 장애에 부딪쳤다. Xfree86, glib, 그리고 gtk+을 추가한 후, 나는 xmms(X11/gtk+ 기반의 MP3/CD 플레이어 애플리케이션)를 넣기로 결정했다. 음악과 함께 기뻐할 시간이 왔다고 생각했다. 그러나 xmms를 설치하고 실행시켰을 때, X 윈도우는 먹통이 되었다. 처음엔 잘못된 컴파일러의 최적화 때문이라고 생각했다("-O6 -mpentiumpro" 옵션을 사용했었다.) xmms를 표준 최적화 옵션으로 컴파일해야 겠다는 이 생각은 문제를 해결해 주지 않았다. 그래서 나는 다른 곳에서 원인을 찾기 시작했다. 문제를 해결하기 위해서 일주일의 시간을 몽땅 허비한 후 Enoch사용자인 Omegadan으로부터 메일을 받았다. 그도 역시 비슷한 문제를 경험했던 사람이었다.
그와 잠시 교신하고 여러 시간동안 테스트한 후, 우리는 그것이 POSIX 쓰레드와 관련된 문제라고 결론지었다. 어떤 이유로 pthread_mutex_trylock() 함수의 호출은 리턴하지 않는 것이었다. 배포판의 창시자로서, 이러한 유형의 버그는 정말 만나고 싶지 않은 것이었다. 개발자들이 완전한 소스를 릴리즈할 것이라고 기대하고, 나는 버그가 많은 소스를 작업하기 보다는 Linux 경험을 늘리는데 집중할 수 있었다. 물론 이것은 비현실적인 기대이고, 이와 같은 문제는 언제든지 드러날 수 있다는 것을 곧 깨달았다.
문제는 xmms, gtk+, 또는 glib에 있는 것이 아님이 드러났다. 또한 Xfree86 3.3.5가 쓰레드 안전(thread-safe) 및 잠금(locking up)에 문제가 있다는 것도 쟁점사항이 아니었다. 놀랍게도, 우리는 GNU C 라이브러리(glibc) 2.1.2의 일부인 Linux POSIX 쓰레드 구현(implementation) 자체의 버그라는 것을 알아냈다. 그때 나는 Linux의 이러한 중요한 부분에도 이러한 큰 버그가 있다는 것을 알고 충격을 받았다. (우리는 Enoch에 glibc의 프리릴리즈 또는 CVS 버전이 아닌 공식 릴리즈 버전을 사용했는데도 말이다!)
그러니 어떻게 그 문제를 찾아낼 수 있었겠는가? 사실상 결코 버그 픽스(bug fix)를 모두 처리해 낼 수 없다. 나는 우연히 glibc 메일링 리스트에서 같은 문제를 가진 다른 사람이 보낸 두개의 메일을 발견하였다. 답신을 한 glibc개발자는 우리를 위하여 그 쓰레드 문제를 해결한 패치(patch)를 부쳐주었다. 그러나 패치는 방금 올라왔고 RedHat 6(glibc 2.1.2 사용)은 이미 사용 가능한 상태였는데, 어째서 RedHat은 이 문제로 고민하지 않았었을까 궁금했다. 이것을 알려고 RedHat의 glibc SRPM(소스 RPM)을 다운로드하여 패치를 살펴보았다.
RedHat은 pthread_mutex_trylock 이슈를 해결한 그들 자신의 glibc 패치를 가지고 있었다. 분명히 그들은 같은 문제에 부딪쳤고 그들 자신의 custom fix를 만들었다. 하지만 그들은 이 패치를 glibc 개발자들에게 "upstream" 보내지 않아서 세상 사람들이 그것을 공유할 수 없었다. 그러나 RedHat은 그 패치를 보냈는데 어떤 이유로 glibc 개발자들이 그것을 받아들이지 않은 이유는 아무도 모른다. 또는 컴파일러와 binutils 버전의 특정한 조합하여 유발되는 쓰레드 버그인데, RedHat은 SRPM에 쓰레드 패치를 가졌을지라도 그 버그에 전혀 부딪치지 않았을 수도 있다. 정확한 내막이 무엇인지 전혀 알 수 없을 것이라고 생각한다. 그러나 나는 RedHat SRPMs는 그들만의 많은 버그 픽스와 미조정(tweak)을 포함하고 있으며, 이러한 것들은 처음의 개발자들에게 결코 다시 보내지지 않았다는 것을 알았다. 이것에 대해서 잠깐 큰소리 좀 쳐야겠다.
큰소리치기
Linux 배포판을 만들 때, 만들어낸 버그 픽스를 처음의 개발자에게 거슬러 보내는 것은 정말 중요하다. 내가 알기로는 이렇게 하는 것이 배포판의 창안자가 Linux에 기여하는 많은 방법 중의 하나이다. 서로 다른 모든 프로그램들을 하나의 통일된 환경에서 작동하게 하는 사람은 바로 우리들이다. 사용자 모두가 하나가 되어 픽스를 거슬러 보냄으로써, 다른 사용자와 배포판이 우리가 발견한 것의 이점을 취할 수 있다. 버그 픽스를 자기 혼자만 알고 있겠다고 한다면, 누구도 돕는 것이 아니다. 다만 많은 사람들이 같은 문제를 픽스하는데 되풀이하고 또 되풀이해서 시간을 허비할 것이라는 것을 알 뿐이다. 이러한 방침은 완전한 오픈 소스(whole open source)라는 가치체계에 역행하고, Linux의 개발 성장을 멈추게 한다. 그러한 방침은 모두를 "골탕 먹인다"고 해도 좋을 것이다.
어떤 배포판은 공동체와 작업을 공유하는데 있어서 어떤 배포판(RedHat)은 다른 배포판(Debian)만큼 좋지 않다는 것은 불행한 일이다.
컴파일러 드라마
glibc 쓰레드 문제의 픽스를 시도하는 동안, 나는 Ulrich Drepper(glibc 개발에 깊숙이 참여한 Cygnus사의 개발자)에게 메일을 보냈다. 나는 우리의 POSIX 쓰레드 문제에 대해서,그리고 Enoch은 최적의 성능을 위하여 pgcc를 사용하고 있음을 보냈다. 그리고 그는 다음과 같이 응답했다. "CodeFusion 제품에 포함된 우리의 컴파일러는 뛰어난 x86 백 엔드(backend)를 가지고 있는데, 이 백 엔드는 pgcc로 생성된 것보다 훨씬 빠른 실행 코드를 생성한다." 분명히 나는 Cygnus사람들이 만든 이 신비에 쌓인 "turbo" 컴파일러를 시험해보는데 큰 흥미를 느꼈다.
거기서 바로 나는 Cygnus CodeFusion 1.0의 데모 카피를 요청했고 그것을 시험해볼 수 있었다. 그리고 Omegadan과 나는 이 컴파일러는 Ulrich가 주장한대로 이고 그 이상이라는 것을 알고 놀랐다. x86 백엔드(backend)는 CPU집중적인 실행코드(예를 들어 bzip2)의 속도를 90퍼센트 가까이 까지 끌어올렸다! 모든 애플리케이션은 실제 속도가 최소한 10퍼센트 증가하는 것으로 보였고, 우리가 해야 할 일은 컴파일러를 교체(swap)하는 것이었다. Enoch도 30~40퍼센트 빠르게 부트 되었다. 속도의 증가는 gcc에서 pgcc로 전환하여 얻은 것보다 훨씬 컸다. 스스로 그것을 경험한 후, 분명히 이 컴파일러를Enoch용으로 쓰고 싶었다. 운 좋게도, 그 소스는 CodeFusion CD에 포함되어 GPL 하에서 릴리즈 되었으므로, 이 컴파일러를 마음 놓고 쓸 수 있었다. 아니, 그렇게 생각했다.
이상한 일이 벌어지다
우리의 생각을 알리려고 Cygnus의 마케팅 매니저에게 메일을 보내면서, "네 가져가세요, 이용해주셔서 감사합니다."라는 대답을 기대했다. 하지만 대답은 다음과 같았다. 우리가 Cynus 컴파일러를 사용하는 것은 (기술적으로) 허용되지만, 그 컴파일러 소스를 Enoch과 함께 사용하거나 또는Enoch에 포함시켜서는 안 된다는 것이었다. 나는, 만일 그렇다면, GPL하에서 소스를 릴리스 한 이유가 무엇이냐는 질문으로 응답했다. 추측하건데, 그들에게 선택이 있었다면 GPL을 사용하지 않았겠지만, 그들의 컴파일러는 egcs(GPL하에서 릴리스)로 부터 파생된 것이었기 때문에 선택의 여지가 없었던 것이다.
이것은 GPL이 어떤 회사가 오픈 소스에 근거하여 독점적(proprietary) 제품을 만들지 못하게 하는 상황의 좋은 예가 된다. 내 경험에 의한 추측은 이렇다. Cygnus는 우리가 그들의 컴파일러를 사용하면, 그들의 박스 제품 판매가 약화된다고 우려한 것이다. 그러나 그들의 어떠한 마케팅 기구도(InfoWorld 리뷰 또한) CodeFusion에 포함되는 새로운 컴파일러를 언급하지 않았기 때문에 특히 이상했다. CodeFusion은 컴파일러가 아니라 통합 개발 환경"development IDE"으로만 판매되는 제품이다.
그들의 편집광을 진정시키려고, 나는CodeFusion을 지지하고 그것의 판매를 도울 링크로서 우리의 웹 사이트에 보증선전(endorsement)을 둘 것을 제의하였다. CodeFusion은 IDE로서 출시되었기 때문에, 개인적으로 "turbo" Enoch이 그들의 판매에 부정적인 영향을 미친다고 생각하지 않았다. 그럼에도 불구하고 나는 그들을 기분 좋게 하려고 하였다. CodeFusion의 구성 요소인 IDE는 상품이었고, 우리는 그것을 Enoch과 함께 배포할 어떠한 욕구와 의도(또는 권리)도 없었다.
나의 (관대한?) 제의를Cygnus에 보냈고 또 다른 이상한 응답을 받았다. 그들은 우리의 모든 "marketing materials"에 대한 권한을 요구했다(또한 분명히 우리의 웹사이트의 컨텐츠도 포함했다!). Cygnus의 마케팅 팀은 Linux공동체 또는 GPL의 작업방식을 전혀 파악하지 못한 것 같았다. 그래서 나는 Cygnus와의 교류를 아주 끊어버리기로 결심했다. 그 동안에 우리는 비공개적으로는 "turbo"이면서 공개적으로는 "non-turbo" Enoch 버전을 만들었고, 최종결정을 뒤로 미루었다.
그러나 몇 달 후Cygnus는 CodeFusion x86 백 엔드를 gcc 2.95.2에 통합했다. CodeFusion CD에 포함된 "비밀의 GPL 컴파일러"에 대하여 아는 사람들은 아니지만, 이제 누구나 새롭고 좋은 백 엔드의 이득을 얻을 수 있었다. 하지만 우리는 계속 진행하면서 CodeFusion 컴파일러보다는 gcc를 사용하기로 결정했다. 보다 안정적인 것에 더하여, gcc 2.95.2를 사용함으로써Cygnus를 피할 수 있었는데, RedHat은 이때까지 터무니없는 가격으로 Cygnus를 구입해왔다. (note: gcc 2.95.2의 새로운 x86 백 엔드는 보다 새로운 Linux 배포판에, 우리가 경험했었던 현저한 속도의 증가를 가져 다 주었다. 그것은 또한 FreeBSD 4.0에 3.3.6을 능가하는 괜찮은 속도증가를 제공했다. 차이점이 보이는가?)
나의 생각
여러 경험들을 통하여, 영리 목적의 오픈 소스 회사들에 대하여 많은 것을 배웠다. 영리 목적의 오픈 소스 회사라는 것이 나쁜 것만은 절대로 아니다. 소스가 폐쇄된(closed-source) 소프트웨어를 독점적으로 생산하는 것이 도덕적으로 또한 나쁠 것은 없다. 그러나 오픈 소스 회사들이 GPL을 지원하지 않거나 또는 다른 어떤 방법으로 나머지 오픈 소스 세계와의 협동을 파괴하거나 거절하는 것은 이치에 맞지 않는다. 이것이 실제적인 사업 감각이다.
오픈 소스 회사들은 아이디어와 코드의 자유로운 교환으로부터 이득을 얻는다는 사실을 알아야 한다. 표준적인 GPL 관행 같은 것에 반대함으로써, 그들이 번창하고 성장하기 위하여 의지해야 할 환경을 해친다. 오픈 소스가 여러분의 사업이 자라기 시작하는 토양이라면, 그 토양을 비옥하게 하는 것이 이치에 맞는다.
단기적인 재정적 소득을 위하여 적어도 어느 정보는 비밀을 유지하고 싶은 유혹이 있을 줄 안다. 고급의 코드 또는 특별한 기법들은 잠재적으로 증가된 판매와 이익을 가져올 수 있는 탐나는 경쟁우위를 제공한다. 그러나 목적이 제품을 독점으로 공급하는 것이라면, 그 제품은 오픈 소스이기보다는 상품이어야 한다. 오픈 소스는 어떤 것의 내부적인 작업에 배타적으로 접근하는 것을 허용하지 않는다. 오픈 소스의 의미이다.
다시 Enoch으로
Enoch가 점점 더 정교해짐에 따라서, 이름을 바꾸기로 결정했고 "Gentoo Linux"가 태어났다. 이때까지 우리는 두개의 Enoch(지금은 Gentoo) 버전을 릴리스 했고, Gentoo Linux 버전 1.0에 노력을 경주하고 있었다. 이 무렵 나는 또한 Celeron 300 박스를(아주 안정적으로 오버클러킹(overclocking)하여 450MHz로 쓰고 있는) 갓 태어난 Abit BP6로(인기를 끌고있는 Celeron 듀얼보드) 업그레이드 하기로 결정했다. 나는 구식의 박스를 팔고, 이중 Celeron 366 시스템을 만들었다. 프로세서를 500Mhz 등급으로 오버클러킹 한 후, 나는 순항하고 있었다. 그러나 새 머신은 매우 안정적이지 않다는 것을 알아차렸다.
나의 첫번째 반응은 2x366Mhz로 다시 내려가는 것이었다. 그러나 더 이상한 문제를 체험했다. 머신이 CPUs를 돌아가게 하는 데는 문제가 없었다. 그러나 머신을 밤새 사용하지않고 idle한 상태로 놔두면, 시스템이 완전히 먹통이 될 가능성이 높았다. 그렇다. idle 버그이다. 면밀히 조사한 후, 이 특이한 머더보드에 같은 문제를 가진 Linux 사용자 몇 사람을 찾았다. BP6의 한 칩이(PCI제어기였던가?) 색다른 것이거나 사양이 아닌 것 같았다. 이것이 Linux를 사용하지 않은 상태에서 먹통이 되도록 만드는 것이었다.
나는 심란했고, 부품을 주문할 여유가 없었기 때문에, Gentoo 개발은 사실상 멈추었다. 나는 Linux에 대하여 점점 더 비관적이 되었고, FreeBSD로 전환하기로 결심했다. 3편에 계속.
배포판 제작하기, Part 3
다시 Linux로
난이도 : 초급
Daniel Robbins, CEO (Gentoo Technologies, Inc.)
2001 년 1 월 01 일
이제 "배포판 제작하기"의 마지막편 이다. Gentoo Linux라는 나 자신의 배포 판 만들기를 어떻게 끝맺음 했는지, 어떻게 해서 Linux 세계를 떠나 FreeBSD로 갔다가 Linux 세계로 다시 돌아와, 새로운 전망을 가지고 Gentoo Linux 개발을 다시 시작하였는지를 설명하고 있다. Linux와 FreeBSD를 비교하고, 또한 현재의 Gentoo Linux 개발의 진척을 설명하고, 배포판에 대한 전망에 대해서도 다루었다.
배포판 제작하기,part 2에서, 이상한 idle-lockup 버그에 의하여 어떻게 Gentoo Linux 개발이 중지되었는지 말했다. 이 lockup은 내가 새로운 Celeron 이중 마더보드로 (Abit BP6) 업그레이드 하자마자 시작된 것이다. 나는 잘 작동하는 시스템이 필요했고 Linux는 항상 lockup되기 일쑤였으므로, BSD 운영체제에 익숙해질 절호의 기회였다. FreeBSD를 설치하여 배우기 시작했고, Linux는 몇 달 동안 손도 대지 않았다.
FreeBSD의 인상
정말로 FreeBSD를 좋아했다. 운영체제는 잘 만들어졌고, 시스템의 모든 부분이 조화하여 Linux 세계에서는 거의 볼 수 없는 높은 수준의 정교함을 보여주었다. 많은 프로그램들이 단지 GNU info 문서만을 보여주는 Linux와는 달리, FreeBSD에는 완전한 맨 페이지들이 들어 있었다.
무엇보다도, 시스템을 유지하고 업그레이드 하는 기술인FreeBSD의 포트 시스템이 인상적이었다. Linux의 접근법과는 달리, FreeBSD의 포트는 이진 패키지를 사용하지 않고 대신에 로컬 머신에서 본래의 소스로부터 모든 것을 자동적으로 컴파일했다. Samba를 설치하거나 코어 시스템을 업그레이드하고 있다면, 모든 것이 바로 여러분의 로컬 머신에서 컴파일된다. 이 방식은 마음에 들었고 Gentoo Linux에서 만들었던 방식과 비슷했다. 많은 부분에서 FreeBSD 설계 방식들은 개발자로서 그리고 시스템 관리자로서 나의 감성에 적합했다. 이러한 까닭으로 FreeBSD는 여러 달 동안 편안한 작업환경을 제공했고, 이렇게 뛰어난 운영체제에 익숙해질 수 있어서 기뻤다.
FreeBSD의 장점
Linux와 FreeBSD의 많은 차이점은 다른 개발구조에서 비롯된다. Linux 개발은 매우 분산되어 있어서, 배포 판에 의지하여 Internet 도처에 흩어져있는 Linux의 여러 부분들을 끌어들여 하나로 만든다. FreeBSD와 다른 BSDs(OpenBSD와 NetBSD)에는 하나의 통일된 소스모음을 꾸준히 연구하는 통합된 개발팀이 있다. 이것은 좋은 방법이라고 생각되며, FreeBSD가 많은 Linux 의 "짜깁기식" 느낌을 가지지 않게 한다.
다음으로 기반기술을 비교할 수 있다. FreeBSD를 좋아하는 사람들은 Linux보다 FreeBSD가 서버로 사용하기에 더 적합하다고 주장한다. FreeBSD는 높은 부하에서 더 수행을 잘하고, 더 나은 TCP/IP 스택을 가지고 있다고 그들은 말한다. Linux 2.2 또는 그 이전 버전을 FreeBSD와 비교하는 거라면 나 역시 동의할 것이다. FreeBSD가 훌륭한 서버 OS인 것은 사실이다. 그러나 그것은 Linux 2.2 또는 그 이전 버전에 대해서다. 나는 내가 사용하고 있는 Linux 2.4 테스트 커널에 푹 빠지게 되었다. 이 커널들은 정말로 훌륭하고, 꾀 좋은 TCP/IP 스택과 정말로 넋을 빼는 완전히 재설계된 "netfilter" 시스템을 포함하고 있다. 결론적으로, Linux는 새로운 성능 표준을 제시하고 자유로운 UNIX 서버가 보다 많은 상업적 경쟁력을 가지도록 할 것이다.
FreeBSD의 단점
데스크톱에 있어서는 사실상 비교가 되지 않는다. Linux가 수지가 맞는다. 최신의 모든 데스크톱 개발은 Linux에 먼저 나타나고, 가속된 3D 그래픽과 사운드 카드 지원에서 Linux는 앞서있다. 커널 2.4를 고려해봐도, Linux는 이 분야에서 우월성을 계속 유지할 것이다.
FreeBSD에서 마음에 들지 않는 점은 UFS 파일시스템을 사용한다는 것이다. UFS는 ext2보다 신뢰할 수 있고 튼튼하지만, 마음이 저리도록 느리다 soft updates라는 특별한 확장판을 사용할 수 있는데, 이것은 IO 조작을 더 큰 덩어리(chunk)로 한데 모아서 파일시스템의 속도를 높일 수 있다. soft updates가 UFS를 크게 개선시키지만, UFS가 사실상 ext2보다 성능이 앞선다고 말할 수는 없다. 물론 안정적인 것은 사실이므로, FreeBSD가 파일시스템에 있어서 Linux보다 낫다고 할 수 있다. 반복하지만 이 또한 Linux 2.2 이하 버전의 경우에 해당된다.
어쨌든, 최신의 Linux 2.2와 Linux 2.4를 FreeBSD에 비교하면 형세가 바뀐다. ReiserFS(새로운 Linux용 저널링 파일시스템)은 놀라울 따름이다. Linux는 또한 ext3, IBM의 JFS, 앞으로의 XFS를 가지고 있는데, 뛰어난 성능과 신뢰도가 기대된다. ReiserFS는 속도를 증가 시키고, Linux 2.4가 FreeBSD가 Linux보다 우월하다는 낡은 주장을 뒤엎는다고 믿는 이유 중의 하나이다.
다시 Gentoo Linux 개발로 돌아오다
몇 달 후, 나는 Linux 세계와 재결합하고 Gentoo Linux를 새로운 개발 박스에서 실행하기로 결심했다. 처음에, Gentoo Linux 개발을 재개하기로 한 결정은 사업적인 의사결정 이상이었다. Linux에 박식해지기 위하여 많은 시간을 투자했고, BSD에 집착하여 이 모든 지식들을 날려버리는 것은 낭비일 것이다. 어쨌든, Gentoo Linux 업데이트를 시작하고 나서 Linux의 새로운 몇 가지 가치들을 발견했는데, 위에서 언급한 모든 파일시스템과 커널의 향상된 점이다. FreeBSD는 아늑한 집이었지만 지루했고 너무 침착했다. Linux는 활기가 넘치고 중요한 진척이 이루어지는 곳이었다. 만약 여러분이 흥미와 혁신을 찾고있다면, Linux가 있는 곳이 바로 그 곳이라는 것에 의심의 여지가 없다.
Linux 2.2는 2.0 시대로부터 실망스러운 감퇴의 시대였지만 2.4 시대는 기다릴만한 가치가 있음을 약속했다. 그래서 Gentoo Linux는 다시 태어났고, 나는 들떠있었다.
Gentoo Linux의 재탄생에는 또 다른 열쇠가 있었는데, 바로 개발팀의 리더인 Achim Gottinger이었다. Gentoo Linux 개발을 다시 시작하는데 도움을 준 Achim에게 이 자리를 빌어서 감사의 뜻을 전하고 싶다. 나는 Linux 세계로 돌아오기 바로 전에 Achim으로부터 메일을 받기 시작했다. 거의 모든 메일에 그는 Gentoo Linux용의 새로운 .ebuild(autobuild) 스크립트 또는 몹시 필요한 버그픽스들을 보내주었다. 내가 Gentoo Linux 개발을 재개함에 따라, Achim은 배포 판이 다시 독립할 수 있도록 그의 시간과 리소스들을 계속 기여해주었다. 최근까지 Gentoo Linux의 작업을 Achim과 나 둘만이 해왔는데, 이것은 선택에 의한 것이었다. 우리 둘은 배포 판에 비슷한 비전을 가졌고, 그리고 Achim의 기술 때문에 엄청난 양의 작업을 할 수 있었고, 세 번째 개발자를 추가한다고 해서 작업이 크게 진척되지는 않을 것이었다. 현재 Achim은 Gentoo Linux 개발을 리드하고 있으며, 거의 매일 Gentoo Linux을 크게 개선시키고 있다. 우리는 다른 사람들이 우리의 CVS 트리에서 작업을 시작하도록 할 준비를 마쳤다. 그리고 점차적으로 조심스럽게 Gentoo Linux 개발팀을 확대하기 시작했다.
새로운 비전
나는 BSD세계에서 보낸 시간들이 어떤 식으로든 허비되었다고 느껴지지 않는다. 사실은 Linux 공동체 전체에서 일어나는 사건들과 Gentoo Linux가 여기에서 개선해 나아가야 할 방법을 돌이켜볼 수 있는 굉장한 기회였다.
Gentoo Linux의 새로운 버전에는 pgcc를 더 이상 사용하지 않고, 모든 바이너리(binaries)를 컴파일하기 위한 매우 높은 최적화 또한 적용하지 않기로 결정했다. 안정성이 최우선으로 고려되어야 하기 때문에, 적당한 ("-O2 -mpentium") 최적화를 사용하지만, 사용자들이 autobuild 시스템을 사용하여 최적화를 기호에 맞게 만들 수 있는 쉬운 방법을 제공할 것이다.
FreeBSD는 나에게 autobuild 시스템의 기능에 관한 정말로 좋은 아이디어를 제공했다. 나는 우리의 autobuild 시스템(지금은 Portage로 불리는)을 진정한 차세대 포트 시스템으로 만들기 위하여 FreeBSD의 몇 가지 특징을 더하기로 결정했다.
Portage는 Gentoo Linux의 중심부이고, 단순한 패키지 관리 또는 유지시스템 이상이다. 내장 툴과 내장 스크립트의 모음으로 구성되는 Portage는 배포 판 전체를 본래의 소스로부터 재구축할 수 있다. 그러나 나에게 더 중요한 것은, Portage는 사용자에게 Gentoo Linux가 구축된 방법에 관한 완전한 지식을 제공한다는 것이다. 우리에게 이것은 매우 중요한 의미를 갖는데, 왜냐하면 Gentoo Linux를 개발해 나가는 동시에 배포판 구축에 대하여 문서화를 진행할 수 있기 때문이다. 그리고, Portage는 사용하고 이해하기 쉽기 때문에, Linux의 내부를 보다 많은 사람들에게 열어서, 다른 사람들도 우리의 소스와 스크립트에 기여할 수 있었으면 좋겠다.
Portage는 Linux 기술을 공개하는 우리의 방식이다. autobuild 스크립트를 배움으로써, 모든 다양한 패키지들이 어떻게 서로 하나의 전체로 맞추어지는지 알 수 있다. 필요하다면, 여러분 자신의 배포 판 또는 Linux 기저의 기술을 만들어가면서, 우리의 CVS트리 전체를 움켜쥐고 잘해나갈 수 있다. ?
상업적 이해관계
시초부터, 다양한 배경을 가진 많은 사람들이 Gentoo Linux 개발에 참여해왔다. 그리고 나는 Gentoo Linux의 돈벌이를 위한 방법을 놓고 개발자들 간에 의견의 차이가 크다는 것을 알고 놀라지 않았다. 기본적으로 두 그룹의 개발자가 있다. 한 그룹은 대개 돈벌이 추구에 반대하고, 반면에 다른 그룹은 Gentoo Linux가 성공적인 상품이 되도록 하는데 흥분해있다. 이것은 예상한 갈림이었다. 첫번째 그룹은 상업적 연루를 오염시키는 영향으로 보는 반면, 두 번째 그룹은 부정적인 관련이 없는 것으로 보았다.
Enoch 시절에 나는 이 쟁점에서 흔들리곤 했는데 올바른 방향을 정말 몰랐다. Debian 같은 배포 판은 그들의 소프트웨어의 자유로운 배포에 정말 전념했다는 사실을 인정했다. 나는 Debian을 사랑했다. 다른 상업적인 배포 판과 비교하여, 그들은 웹사이트에 상세한 지식들을 제공함으로써 사용자들을 편하게 해주었다. 그것은 참 훌륭한 일이며, 내가 흉내내보고 싶은 것이었다.
동시에 Gentoo Linux가 상업적으로도 성공하기를 간절히 원했다. 균형 점을 찾으려고 노력했지만, 최근까지도 전혀 찾지 못하였다.
절충방안
상업적인 이익과 비상업적인 이해관계를 어떻게 절충할 수 있을까? 방법은 우리의 기반을 상기하는 것이다. Gentoo Linux의 기반은 오픈 소스 소프트웨어이다. 그래서 우리의 모든 노력의 밑바탕은 오픈 소스에 초점을 맞추어야 한다. 오픈 소스 소프트웨어를 인정하기만 하거나 또는 그것을 사용하는 것만으로는 충분하지 않다. 또한 오픈 소스의 개발과 배포를 격려해야 하고, 상업적 이득을 위하여 이 입장에 반대해서는 안 된다. 보다 중요하게, 소스의 자유로운 배포를 제한하려는 유혹이 도사리는 그러한 사업 모델을 구축해서는 안 된다. 개발팀은 대중에게 공개되고 그들이 접근할 수 있어야 하고, Gentoo Linux의 자유로운 배포는 허용될 뿐만 아니라 격려되어야 한다. 우리는 말 뿐만이 아닌 행동으로도 오픈 소스의 옹호자가 되어야 한다.
어떤 회사가 상업적인 Linux 기반 기술을 위하여 Gentoo Linux를 사용하고 싶다면, 우리의 모든 제작물은 GPL 하에서 배포되기 때문에, 그들은 우리의 CVS 트리의 컨텐츠를 손에 넣어 사용할 수 있다. 모든 이차적인 제품들은 GNU Public Lisence 에 따라야 한다는 것을 제외하고, 우리의 제작물을 사용하는데 어떠한 제한도 두고 싶지 않다.
여러분이 Gentoo Linux를 제품의 기초로 사용하는 회사의 일원이라면, 자유로이 배포될 수 있는 어떠한 개선사항이라도 우리에게 보내어, 우리가 그것을 CVS 트리에 추가할 수 있기를 희망한다. 그러한 방식은 모든 사람에게 이익이 된다. 여러분이 추가한 것을 우리는 계속 관리하고 개선할 수 있으며, 교대로 여러분은 이러한 개선점들을 이용할 수 있다. 우리는 상업적인 것과 비상업적인 것 사이의 협력을 촉진하고 싶다. 이 방식으로 ISP(Internet service provider)에Gentoo Linux를 사용하는 시스템 관리자와 상업적인 서버 제품을 구축하는 기업 모두는 서로의Gentoo Linux 개선점과 픽스에서 이익을 얻을 수 있다. 모든 사람들 사이에서 코드의 자유로운 교환을 촉진할 때인 것이다. 오픈 소스만이 이것을 가능케 할 수 있다.
앞으로의 전망
우리는 Gentoo Linux 1.0을 배포하려고 한다.(여러분이 developerWorks에서 이 글을 읽을 때는 사용 가능할 것이다.) 하지만 앞으로는 어떻게 될까?
우리가 2.0으로 향함에 따라, Gentoo Linux의 핵심 기술인 Portage가 계속 개선되기를 바란다. Gentoo Linux의 중요한 개선은 대개 Portage에서 시작된다. 나는 코드의 대부분을 bash에서 python으로 변환하는 과정을 계속하고 싶다. 이렇게 하여 우리의 autobuild 시스템에 객체지향적 설계와 같은 새로운 특징을 추가할 수 있을 것이다.
Portage의 변화에 더하여, 우리와 비전을 함께하는 숙련된 개발자들을 찾아내어 우리의 개발팀을 서서히 조심스럽게 키우고 싶다. 개발팀이 커감에 따라, Gentoo Linux 용의 autobuild 스크립트의 수를 크게 증대할 수 있을 것이다. 그러나 이보다 더욱 중요한 것은, 조금 더 큰 개발팀은 Linux 기술을 계속 발전시키는데 필요한 리소스를 제공할 것이다. 거기에 즐거움이 있다.
상업적인 Linux 기술 회사들이 그들 제품의 기초로서 Gentoo Linux를 선택하기를 또한 기대한다. 현재 한 회사와 이러한 관계를 맺고 있으며 앞으로 더 많아지기를 기대한다. 이러한 협력은 많은 즐거움과 모든Gentoo Linux 사용자에게 큰 이익을 약속한다.
결국, 우리의 일차적인 목표는 Linux 공동체에 의미 있는 어떤 것을 기여하는 것이다. 비록 선택할 Linux 배포 판들이 많이 있을지라도, Gentoo Linux는 다른 곳에서는 실제로 사용 가능하지 않은 것도 제공한다. 우리는Gentoo Linux 개발의 미래에 대해 기대에 차 있으며, 여러분도 또한 그러리라고 믿고 싶다.
필자소개
Daniel Robbins는 Gentoo Technologies, Inc.의 회장/CEO이고, Gentoo Project의 핵심 설계자이며, Caldera OpenLinux Unleashed, SuSE Linux Unleashed, Samba Unleashed의 저자이다.
'Linux' 카테고리의 다른 글
| The GNU Manifesto (0) | 2006.09.16 |
|---|---|
| GNU 선언문(The GNU Manifesto) (0) | 2006.09.16 |
| Making the distribution, Part 3. The author strays from Linux and then returns (0) | 2006.09.16 |
| Making the distribution, Part 2. From Enoch to Gentoo, via minor setbacks and corporate run-ins (0) | 2006.09.16 |
| Making the distribution, Part 1. Birth of the Gentoo Linux distribution (0) | 2006.09.16 |
|
Level: Introductory Daniel Robbins (drobbins@gentoo.org), President/CEO, Gentoo Technologies, Inc. 01 Jan 2001 This article concludes my story -- about how I ended up creating my own distribution called Gentoo Linux. I wrap up the series by telling how I left the Linux world to move to FreeBSD, and then came back to the Linux world, restarting Gentoo Linux development with a fresh perspective. In addition to comparing Linux and FreeBSD in a number of areas, I also describe current Gentoo Linux development progress and share a future vision for our distribution.
All in all, I really liked FreeBSD. I felt that the operating system was well put together and that nearly every part of the system had a consistently high-level of refinement that's almost never found in the Linux world. I enjoyed the fact that FreeBSD contained a full complement of man pages, unlike Linux where many programs only have GNU info documentation, which I don't particularly like using. Most of all, I was impressed with FreeBSD's ports system, the technology used to maintain and upgrade the system. Unlike the Linux approach, ports didn't use binary packages but instead automatically compiled everything locally from their original sources. Whether you were installing Samba or upgrading the core system, everything was compiled right on your local machine. This approach appealed to me and was very similar to the one I had been creating under Gentoo Linux. In this and many other ways, FreeBSD's design agreed with my sensibilities as a developer and a system administrator. For this reason, FreeBSD provided a comfortable work environment for many months, and I'm glad I took the time to get familiar with this excellent operating system. A lot of the differences between Linux and FreeBSD come from their different development structures. Linux development is very decentralized, and we rely on distributions to pull in and unite the various pieces of Linux scattered throughout the Internet. Compare this to FreeBSD and the other BSDs (OpenBSD and NetBSD), where there's a unified development team plugging away at a single, unified set of sources. Well, at least each BSD has its own set of unified sources. This can be a good thing, and results in FreeBSD not having a "patched together" feel like many Linux distributions do. Next, we can compare the technology under the hood. Many a FreeBSD fan will assert that FreeBSD is better suited to being a server than Linux is. They'll tell you that FreeBSD is better under high loads, and has a better TCP/IP stack. If you're comparing Linux 2.2 or earlier with FreeBSD, I'd have to agree. FreeBSD is a great server OS, that's for sure. But, that's just Linux 2.2 and earlier. I happen to be a big fan of the 2.4 test kernels that I've been running. They're really, really great and contain a nice TCP/IP stack and a totally redesigned "netfilter" system that really rocks. In the end, I think that Linux will be the one to set new performance standards and make free UNIX servers even more competitive versus their commercial counterparts. As for the desktop, rather than the server world, there's really no comparison -- Linux is where the action is. All the latest desktop developments appear on Linux first, and Linux is ahead in its support of accelerated 3D graphics and sound cards. With Linux 2.4 approaching, Linux will continue its dominance in this area. The one thing I don't like about FreeBSD is its use of the UFS filesystem. While UFS is more reliable and rugged than ext2, it's also mind-numbingly slow. It's possible to use a special UFS extension called soft updates, which is able to speed up the filesystem by aggregating IO operations into bigger chunks. While soft updates improves UFS tremendously, I can't say that UFS really outperforms ext2 in any way. Of course, it's more reliable, so FreeBSD ends up beating Linux in the filesystem war. Again, at least this is true when comparing older Linux 2.2 distributions to FreeBSD. However, the tables turn when we start to compare modern Linux 2.2 and Linux 2.4 to FreeBSD. ReiserFS (a new journalling filesystem available for Linux) is just amazing. Linux also has ext3, IBM's JFS, and XFS to look forward to, from which we expect excellent performance and reliability as well. As of now, ReiserFS gives Linux a major speed advantage over FreeBSD, and is one of the reasons I believe that Linux 2.4 overturns many of the old arguments of FreeBSD's superiority over Linux.
After a few months, I decided to rejoin the Linux world and get Gentoo Linux running on a new development box. At first, the decision to restart Gentoo Linux development was more of a business decision -- I had invested a lot of my time in becoming Linux-knowledgeable, and it would be a waste to throw all this knowledge away by sticking with BSD. However, shortly after I began updating Gentoo Linux, I found several new reasons why Linux was worth switching back to, namely all the filesystem and kernel improvements mentioned above. FreeBSD was a peaceful home, but a little too boring, too staid. Linux is where the action was, where major progress was being made. There's no doubt that if you're looking for excitement and innovation, Linux is the place to be. To me, the Linux 2.2 era was a disappointing letdown from the 2.0 era, but the 2.4 era promised to be worth the wait. So, Gentoo Linux was reborn, and I was excited. There was another key to Gentoo Linux's rebirth -- Achim Gottinger, my development team lead. I want to take some space to thank Achim for helping me restart Gentoo Linux development. I started getting e-mails from Achim shortly before my return to the Linux world. In almost every e-mail, he'd include some new .ebuild (autobuild) scripts for Gentoo Linux, or some desperately needed bugfixes. As I restarted Gentoo Linux development, Achim continued to contribute his time and resources to help get the distribution back on its feet. Up until recently, Achim and I have been the only two people working on Gentoo Linux, and this has been by choice. Because we both have a similar vision for the distribution, and because of Achim's skill, we were able to get a tremendous amount of work done and I never really felt that adding a third developer would significantly help our progress. Now, Achim serves as the Gentoo Linux development lead, and continues to make major improvements to Gentoo Linux on an almost daily basis. We've reached the point where we're ready for others to start working on our CVS tree, and have begun to gradually and carefully expand the Gentoo Linux development team. I don't feel that the time I spent in the BSD world was in any way wasted. In fact, it gave me a tremendous opportunity to reflect on the happenings in the entire Linux community and how Gentoo Linux could help to improve things. In the new version of Gentoo Linux, I made the decision to not use pgcc anymore, nor use very high optimizations to compile all binaries. Since stability was paramount, we would use reasonable ("-O2 -mpentium") optimizations but provide an easy way for users to customize these optimizations to their liking by using our autobuild system. FreeBSD gave me a really good idea of how an autobuild system should function. I decided to add several FreeBSD features to make our autobuild system (now called Portage) a true next-generation ports system. Portage is the heart of Gentoo Linux, and is more than a simple package management or maintenance system. Consisting of a set of build tools and build scripts, Portage allows you to rebuild the entire distribution from original sources. But more importantly to me, Portage gives the user full access to the intelligence of how Gentoo Linux was built. To us, this is very important because it means that we are documenting how to build a distribution while at the same time moving Gentoo Linux development forward. And, because Portage is easy to use and understand, we hope that it will open up Linux internals to even more people, so that others can begin to contribute to our sources and scripts. Portage is our way of opening up Linux technology to others. By studying the autobuild scripts, you can see how all the various packages fit together into a unified whole. If necessary, you can grab our entire CVS tree and hack away at it, producing your own custom distribution or Linux-based technology. We believe that this is a good thing -- we want to give people the knowledge they need to take Linux into new realms. Since its inception, there have been many people of various backgrounds involved with Gentoo Linux development. And I wasn't surprised to find that our developers had wildly different opinions of how we should approach the money-making end of Gentoo Linux. Basically, there were two groups of developers: one group was generally opposed to money-making pursuits, while the other group was excited about helping Gentoo Linux become a successful commercial product. This was an expected split; the first group saw commercial involvement as a corrupting influence, while the second saw no such negative associations. In the Enoch days, I used to waver on this issue and didn't really know the right approach. I recognized the fact that distributions like Debian were truly committed to free distribution of their software. I liked that. Compared to other commercial distributions, they made things easy for the user by providing detailed instructions on their Web site. That was a good thing, and something I wanted to emulate. At the same time, I really wanted Gentoo Linux to be commercially successful. I struggled to find a balance, but never really found one until recently. So, how are we planning to balance commercial and non-commercial interests? The key is to remember our foundation -- the foundation of Gentoo Linux is Open Source software. Thus, the foundation for all our endeavors must focus on Open Source. It's not good enough to just acknowledge Open Source software, or just to use it. We must also encourage its development and distribution, and never oppose this stance for commercial gain. More importantly, we must never structure our business model so that there's a temptation to restrict the free distribution of our sources. Our development team needs to be open and accessible to the public, and free distribution of Gentoo Linux must not only be allowed, but encouraged. We need to be Open Source advocates, not just in word, but in action also. If a company wants to use Gentoo Linux for a commercial Linux-based technology, they can just grab the contents of our CVS tree and start using it, since all our work is distributed under the GPL. We don't want to limit the use of our work in any way, except to ensure that all derivative products comply with the GNU Public License. We'd like as many people as possible to benefit from our work, but we'd also like to benefit as much as possible from your improvements to Gentoo Linux. If you're part of a company using Gentoo Linux as a base for your product, we hope that you'll send any freely-distributable improvements to us so that we can add them to our CVS tree. That way, everyone benefits. We can continue to maintain and improve your additions, and you in turn can benefit from these improvements. We want to foster collaboration between commercial and non-commercial entities. This way, both the sysadmin using Gentoo Linux at his ISP and the corporation building a commercial server product can benefit from each other's improvements and fixes to Gentoo Linux. It's time to promote the free exchange of code between everyone. Only Open Source makes it possible. Right now, we're at the verge of releasing Gentoo Linux 1.0 (it may be available by the time you read this article on developerWorks.) But what does the future hold? As we move towards 2.0, I hope to continue to improve Portage, the technology at the heart of Gentoo Linux. Any major improvement to Gentoo Linux generally starts with an improvement to Portage. I'd like to continue the process of converting the majority of the code from bash to python, which will allow us to add new features like object-oriented design to our autobuild system. In addition to changes to Portage, I hope to continue to slowly and carefully grow our development team by finding skilled developers who share our same vision. As our development team grows, we will be able to vastly expand the number of autobuild scripts available for Gentoo Linux. But even more important than this, a slightly larger development team will give us the resources we need to continue to keep Gentoo Linux on the cutting edge of Linux technology. That's where the fun is :) We also hope that commercial Linux technology companies will choose Gentoo Linux as a base for their products. We currently have one such relationship and we hope to have many more in the future. These kinds of collaborations promise to be lots of fun and to be a great benefit to all Gentoo Linux users. In the end, our primary goal is to contribute something meaningful to the Linux community. Although there are many Linux distributions to choose from, we know that Gentoo Linux offers something that really isn't available anywhere else. We're excited about the future of Gentoo Linux development, and we hope you are too.
| |||||||
'Linux' 카테고리의 다른 글
| The GNU Manifesto (0) | 2006.09.16 |
|---|---|
| GNU 선언문(The GNU Manifesto) (0) | 2006.09.16 |
| Gentoo Linux 배포판의 탄생 (0) | 2006.09.16 |
| Making the distribution, Part 2. From Enoch to Gentoo, via minor setbacks and corporate run-ins (0) | 2006.09.16 |
| Making the distribution, Part 1. Birth of the Gentoo Linux distribution (0) | 2006.09.16 |
|
Level: Introductory Daniel Robbins (drobbins@gentoo.org), President/CEO, Gentoo Technologies, Inc. 01 Dec 2000 In his previous article, Daniel Robbins told the story of how he became a Stampede Linux developer and why he eventually left Stampede to start the Enoch Linux distribution. In this go-round he lets you in on the strange events that happened after the Enoch development team discovered a little-known, blazingly fast compiler. First steps to Enoch In my previous article, I gave you the low-down on my days with the Stampede development team and why I left (to get away from lower-level politically-minded, project-controlling "freaks"). Because of the interference from these meddlesome by-standers, I figured it would be easier to put together my own Linux distribution than to continue improving Stampede under such dirty conditions! Fortunately I took with me a considerable amount of experience based on my (may I say substantial?) work for Stampede, including maintaining several of their packages, designing the initialization scripts, and leading the slpv6 (next-generation package management project). The distribution I began working on, code-named Enoch, was going to be blazingly fast because it would completely automate the package creation and upgrading process. I have to admit that this was in large part because I was a one-member team and couldn't afford to spend my time on repetitive work that my development box could be automated to do for me. And since I was designing a complete distribution from scratch (rather than "spinning off" from someone like RedHat), I had my work cut out for me and needed all the free time I could scrounge up. After getting my basic Enoch system up and running, I headed back to irc.openprojects.net and started my own channel called #enoch. From there I gradually assembled a team of about ten developers. In those early days we all hung out on IRC and worked on the distribution in our spare time. As we communally and cooperatively hacked away at it, finding and fixing new bugs, Enoch became more functional and professional every day. One inevitable day, Enoch hit its first roadblock. After adding Xfree86, glib, and gtk+, I decided to get xmms (an X11/gtk+-based MP3/CD player app) working. I figured it was time to celebrate with some music! But after installing xmms, I tried to start it... and X locked up! At first I thought xmms locked up because I used insane compiler optimizations ("-O6 -mpentiumpro", in case you were wondering). My first thought, to compile xmms with standard optimizations, didn't solve the problem. So I started looking elsewhere. After spending a full week of development time trying to track down the problem, I got an e-mail from an Enoch user, Omegadan, who was also experiencing xmms lockups. We corresponded for a while, and after many hours of testing we determined that the problem was a POSIX threads-related issue. For some reason, a pthread_mutex_trylock() call did not return the way it should. As the creator of a distribution, these were the types of bugs I really didn't want to encounter. I counted on the developers to release perfect sources so I could focus on enhancing the Linux experience rather than getting buggy sources to work. Of course I soon learned that this was an unrealistic expectation, and that problems like will always pop up from time to time. As it turned out, the problem wasn't with xmms, gtk+, or glib. And it wasn't an issue with Xfree86 3.3.5 not being thread-safe and locking up. Surprisingly, we found the bug in the Linux POSIX threads implementation itself, part of the GNU C library (glibc) version 2.1.2. I was shocked at the time to find that such a critical part of Linux had such a major bug. (And we used a release version of glibc in Enoch, not a prerelease or CVS version!). So how did we track down the problem? Actually, we never were able to come up with a bug fix, but at one point I stumbled across a couple of e-mails on the glibc developer mailing list from another person who had the same problem. The glibc developer who replied posted a patch that solved the thread problem for us. But I was curious why RedHat 6 (which also used glibc 2.1.2) didn't suffer from this problem since the patch was just posted and RedHat 6 had been available for some time. To find out, I downloaded RedHat's glibc SRPM (source RPM) and took a look at their patches. RedHat had their own homegrown glibc patch that solved the pthread_mutex_trylock() issue. Apparently they experienced the same problem and created their own custom fix. Too bad they didn't send this patch "upstream" to the glibc developers so it could be shared with the rest of the world. But who knows, maybe RedHat sent the patch upstream and for some reason the glibc developers didn't accept it. Or maybe the thread bug was triggered by a specific combination of compiler and binutils versions, and RedHat never ran into it (although they did have a thread patch in their SRPM). I suppose we'll never know exactly what happened. But I did learn that RedHat SRPMs contain a lot of private bug fixes and tweaks that never seem to make it upstream to the original developers. I'm going to rant about this for a little while. When you put together a Linux distribution it's really important that any bug fixes you create are sent upstream to the original developers. As I see it, this is one of the many ways that distribution creators contribute to Linux. We're the guys who actually get all these different programs working as a unified whole. We should send our fixes upstream as we unify so that other users and distributions can benefit from our discoveries. If you decide to keep bug fixes to yourself, you're not helping anyone; you're just ensuring that a lot of people will waste time fixing the same problem over and over again. This kind of policy goes against the whole open source ethic and stunts the growth of Linux development. Maybe I should say that it "bugs" us all.
During the time we were trying to fix the glibc threads problem, I e-mailed Ulrich Drepper (one of the guys at Cygnus who is heavily involved with glibc development). I mentioned the POSIX thread problem we were having, and that Enoch was using pgcc for optimum performance. And he responded with something like this (I'm paraphrasing here): "Our own compiler included with the CodeFusion product has an excellent x86 backend that produces executables far faster than those generated with pgcc." Obviously, I was very interested in testing out this mystery "turbo" compiler the Cygnus guys had created.
I sent an e-mail to the marketing manager at Cygnus to let them know our intentions, expecting a "yeah, go for it, thanks for using our compiler" response. Instead the reply was that although we were (technically) allowed to use the Cygnus compiler, we were strongly urged not to use or include the compiler sources with Enoch. I responded by asking why they had released the source under the GPL, if that was the case. It's my guess that if they had a choice, they wouldn't have used the GPL, but because they derived their compiler from egcs (released under the GPL), they had no choice. This is a good example of a situation where the GPL prevented a company from creating a proprietary product based on open sources. My educated guess is that Cygnus was afraid that if we used their compiler we would undermine their boxed product sales, which would be especially strange because none of their marketing materials (nor the InfoWorld review) mentioned the new compiler included with CodeFusion. CodeFusion was marketed solely as a "development IDE" product, not as a compiler. In an attempt to put some of their paranoia to rest, I offered to endorse CodeFusion and place the endorsement on our Web site with a link to help spur CodeFusion sales. Personally I didn't think that a "turbo" Enoch would negatively affect their sales, since CodeFusion was marketed as an IDE. But I tried nevertheless to make them happy. The IDE component of CodeFusion was a commercial product, and we had no desire or intention (or right) to distribute it with Enoch. I e-mailed my (generous?) offer to Cygnus and received another strange response. They wanted authority over all of our "marketing materials" (apparently, this also included the content of our Web site!) Another shocker. The Cygnus marketing team seemed to have no grasp of how the Linux community or the GPL worked, so I decided to cut off communication with Cygnus for the indefinite future. In the mean time, we created a private "turbo" and public "non-turbo" version of Enoch, leaving the final decision for later.
Thanks to this and other experiences, I've learned a lot about for-profit open source companies. There's absolutely nothing bad about being a for-profit open source company. Nor is there anything morally wrong with producing proprietary closed-source software, if that's what you'd like to do. But it doesn't make any sense for open source companies to subvert or refuse to cooperate with the rest of the open source world, either by not supporting the GPL or by any other means. This is a practical point that clearly makes business sense. Open source companies should realize that the free exchange of ideas and code is what they profit from. By opposing things like the standard GPL practices, they undermine the environment they rely upon to prosper and grow. If open source is the soil from which your business has sprouted, it makes sense to keep the soil healthy.
Now, I'll step down from my soapbox and continue my story. As Enoch became more and more refined, we decided that a name change was in order, and "Gentoo Linux" was born. By this time we had released a couple of versions of Enoch (now Gentoo), and were racing to get to Gentoo Linux version 1.0. Around this time I also decided to upgrade my old Celeron 300 box (overclocked and rock-solid at 450Mhz) to a brand-new Abit BP6 (a dual Celeron board that had just hit the market). I sold my old box and put my dual Celeron 366 system together. After overclocking the processors to something on the order of 500Mhz, I was cruising. But I noticed that my new machine wasn't very stable. Obviously my first reaction was to go back down to 2x366Mhz. But now I experienced an even stranger problem. As long as my machine kept the CPUs chugging away, the machine didn't lock up. But if I left the machine idle overnight, there was a good probability that the system would lock up completely. Yes, an idle bug -- argh! After some research, I found several other Linux users with the same problem on this particular motherboard. A chip on the BP6 (was it the PCI controller?) seemed to be flaky or out of spec, which caused Linux to lock up at idle. I was more than a wee bit upset, and because I couldn't afford to order more PC parts, Gentoo development effectively halted. I became more and more pessimistic about Linux and decided to switch over to FreeBSD. Yes, FreeBSD. And that's where I'll end this installment -- see you in Part 3. :) |
'Linux' 카테고리의 다른 글
| The GNU Manifesto (0) | 2006.09.16 |
|---|---|
| GNU 선언문(The GNU Manifesto) (0) | 2006.09.16 |
| Gentoo Linux 배포판의 탄생 (0) | 2006.09.16 |
| Making the distribution, Part 3. The author strays from Linux and then returns (0) | 2006.09.16 |
| Making the distribution, Part 1. Birth of the Gentoo Linux distribution (0) | 2006.09.16 |
|
Level: Introductory Daniel Robbins (drobbins@gentoo.org), President/CEO, Gentoo Technologies, Inc. 01 Nov 2000 Each of us has a story to tell about our experiences with Linux. This is Daniel Robbins' Linux story. In this first of three articles, he talks about how he became a Stampede Linux developer, and why he eventually left Stampede to start his own distribution called Enoch. Linux and me For every Linux geek there's a time when Linux becomes more than just a name and reveals itself as something more wonderful, powerful, and intriguing than anything a developer has ever encountered. My revelation came while I was working at the University of New Mexico as a sysadmin. Our NT server was running pretty well and I had some extra time on my hands. So I got Debian set up on a Pentium 166 server box and started learning ... and learning and learning and learning. And then I was hooked. First I learned the basic ins and outs of Linux: how to get around, perform backups, get Samba running, etc. Then I set up qmail and Apache and learned python and shell programming. I built a departmental Intranet. I got Linux installed at home and began trying different distributions. Finally I settled with Stampede Linux. You know how the progression goes: first you struggle with grasping Linux basics; then, when you have a decent grip, you customize your Linux, learning as you go. Because Linux has nothing to hide, you can explore the technology and tools that make it tick while you grow in Linux fluency. Linux offered something I had never seen before. If I had to put that magical something into words, I'd call it potential: the potential to change, to improve, to fix things, and yes, even to break things. As I upgraded to new kernel versions I saw Linux improve before my eyes and transform itself almost daily. And I was along for the ride! I was a part of the transformation. It was fun. If you're anything like me, before you were exposed to Linux and open source you looked to those big companies in Redmond and Cupertino to provide a next-generation operating system that finally worked exactly the way you wanted it to. But alas, that dream never became reality. And while we were waiting, Linux came along. And although it had a lot of rough edges, it provided something for us hacker guys and gals that we could improve upon while we waited for the next big thing. Then one day we awoke to find that Linux had become the next big thing. And smiling all the while, we continued to hack away. The next thing I learned was that Linux is about people. Isn't that refreshing? Linux isn't just a bunch of source code. It's a community. We rely on this community to get our questions answered, and we become part of the community when we start helping others by contributing our time and expertise. IRC (Internet relay chat) is a great place to meet people and waste a tremendous amount of time. The #stampede channel on irc.openprojects.net became my official hangout. That's where I'd ask my Linux questions. It's also where I first began to help other people out. #stampede desperately needed experienced Linux users to help out newbies who had just gotten the distribution installed. As is common on IRC, many of the experienced Stampede people had lost their zeal for answering (yet another) newbie question. But I was so excited that I actually knew the answer to newbies' questions, that I couldn't resist helping out! And that's how my involvement with Stampede began. I was just another guy who liked to answer questions. Of course, it wasn't entirely altruistic, because I also helped myself to expert Linux knowledge that the more experienced people on the channel (not to mention the Stampede developers themselves!) had to offer. When people ask me how to get involved in an open source project, I tell them to find a place where they can be helpful, even if it's just by helping with basic Linux questions. A sincere desire to help others is a great ticket into the Linux community because this sentiment is at the heart of all open source development (including Linux). At least, it should be. Along the way you'll inevitably run into people who know more than you. And you'll learn from them just as newbies continue to learn from you. It's also likely that as you gain more experience you'll come across opportunities to help in new ways. Maybe some of the project developers you come across will suggest something, or they'll ask for help themselves. They may even invite you to become part of the development team. If you're focused on helping others, they'd be foolish to pass you by. If you're helping a lot of people out, you will definitely be noticed in the community. That's sort of how it happened with Stampede and me. Gradually I became more and more involved in Stampede development. Before long, I was an official Stampede developer. With the blessing of skibum (Matt Wood, Stampede's head honcho), I began working on a new version of Stampede's primitive .slp packaging format. At the time the .slp package format consisted of a .tar.bz2 archive with a fixed-length footer stuck on the end that contained information about the package author, a description of the contents, the package creator, etc. This approach had two major problems: the fields were a fixed length and the footer really wasn't that big, and there was no extensibility built into the format (there was no way to add any additional fields to the .slp format in the future). Obviously this thing needed a major overhaul. Working with the senior Stampede developers, I wrote up a proposal of how to deal with the problem. Then I started coding the prototype tools in Python. The new format (codenamed slpv6) was somewhat similar to the IFF file format from the Amiga world. This next-generation .slp format allowed for 2 32 fields, 2 32 categories of fields, and a maximum field data length of 2 32 bytes. Not only was the format very extensible, it was also more compact than plain-text and easy to parse. Both text and binary data could be stored in the format, which allowed for a lot of possibilities for the future. The idea was to stick this next-generation dynamic header on the end of the archive file, thereby producing a next-generation .slp format that would serve Stampede users for years to come and at the same time maintain compatibility with standard UNIX archive formats. slpv6 development was going well and all the senior developers were happy with my progress. But unfortunately, two lower-level Stampede developers wanted to control the slpv6 project. They didn't like the direction I was taking, and they spent most of their time insulting the new slpv6 system. Though I spent hours in heated development discussions defending the proposal against their attacks, we weren't able to resolve anything. Eventually it became clear that they were just naturally argumentative and wouldn't be happy until they had their way. Fortunately for me, my project had the approval of the senior Stampede developers. But these discussions began to wear on me and made Stampede development very unpleasant. Ugh! I couldn't avoid these guys since I had to hang out on #stampede to chat with higher-level developers. And every time I was on the channel they became combative, trying to undermine my work. They'd use devious techniques like calling for development meetings (really just an opportunity to insult my work in front of the senior developers). They'd also try to call for votes, attempting to seize control of Stampede. Of course they'd only call for a vote when they thought they had convinced enough people to agree with them. Throughout all of this I continued my slpv6 development. Needless to say, the senior development loved my work and wanted me to continue (without their support I wouldn't have been able to stick it out). These two guys belong to a category of developer I like to call "the freak". But although they made my development work very unpleasant, I also learned a lot from having to deal with them. At this point I'd like to offer you an expos?f the freak developers, a sort of comprehensive overview: the qualities that make a freak, the freak's modus operandi, and how you, the development project leader, can confront and possibly reform the freak without exerting a lot of effort. In order to avoid emotional damage, you'll need one prerequisite: a backbone. If you're unable to confront the freak in a respectful but firm manner, there's no hope. The freak's goal is to control as much of your project as possible so that he or she will feel powerful. The freak will use several techniques to make this happen. First they'll start unfairly criticizing or bitterly complaining about a project and/or the developers working on a project. Then they will refrain from offering any constructive solutions. They will also not be willing to help with the project in any other way unless they are promoted to the role of project manager. Their goal is to convince you to give them as much authority as possible so that they can solve problems that only they, with their finely trained freak eyes, can see. If the criticism and complaining aren't effective, they'll request a developer meeting. This will be their opportunity to try and divide your development team into two factions. When they think that they've gotten enough people on their side, they'll request a vote (knowing they will win). If they don't win the vote or they are overruled, they'll push for another developer meeting next week in which they'll again try to divide your development team. They'll repeat this process endlessly. If the developer meeting approach doesn't work, freaks will become reformers. By adopting this role they will try to streamline (read: undermine) the oppressive and unfair executive decision-making process by attempting to replace it with something more democratic (read: easily manipulated.) This will often involve convincing you that you should do whatever the majority of your developers want. Freaks love this because then you can't override those developer meeting votes anymore (muhahaha!). If you allow this to happen, you've basically given the freak the keys to your Lexus. You're powerless. In another approach, freaks will irritate and drive away your productive developers. Then they'll work your entire team into a frenzy as they forcefully try to reform the project's power structure. If their efforts are finally defeated, they'll try to rally as many defectors together as possible and fork from your project. Ouch! You can identify these guys pretty easily. They're the ones who aren't writing any code (nor do they have any intention to). Instead they spend their time talking about more important things. You know, those managerial issues. If you're a project leader, it's pretty easy to deal with them. Just tell them that you won't consider any proposal unless they produce working code. Or insist that they constructively help the current project, which includes obeying the current project manager, before giving them the opportunity to offer any (constructive) criticism. If they write some nice code or start being more helpful, great. If not, tell them to go away. They'll either leave the project (if you ignore them long enough), or they'll get their act together and start writing some code and generally become more pleasant. Unfortunately the senior Stampede developers didn't take on freak management. In other words, they allowed these two guys to pester me (and others) to no end. While the senior developers were always in favor of my development work, they didn't do much to get these guys under control. So one day I decided that it would be easier to create my own distribution rather than have to put up with the two freaks. I resigned from Stampede development and started making plans to produce my own distro. While I felt a bit weird about leaving a project because of two lower-level developers, the fact that they weren't dealt with really indicated that the project had severe managerial problems. If the higher-level developers weren't able or willing to make sure the Stampede development effort was pleasant and rewarding, then I didn't want to be there. Once I left I breathed a big sigh of relief. Wow! Finally, things were calm and quiet. Now it was time to define what my distribution would be about and what it would contribute to the Linux distribution scene. One of the things that attracted me to Stampede was its raw performance (thanks to its use of the experimental Pentium-optimized pgcc compiler). So I decided to focus first on performance. In addition to minimizing CPU utilization, I also wanted to minimize bloat. Too many distributions (especially those popular shrink-wrapped ones) enable so many daemons by default that you barely have any RAM left after opening an xterm. I wanted my distribution to be lean and mean, and focused on maximizing the performance of the hardware that it ran on. I decided to take a holistic approach and tackle the performance problem from all angles. But I had a serious lack of resources, since I was the only developer for my distribution! How could I possibly create something that was comparable to Caldera or RedHat off the ground on my own? The answer was automation. I had to write scripts to automate everything, so that I would have a minimal amount of time-consuming, repetitive labor. After all, that's what computers do best, right? I quickly saw that writing simple scripts for the kind of automation I needed wasn't going to be enough. I needed to design a complete system for generating a Linux distribution from scratch. I tentatively called it the ebuild system and got to work. The ebuild system would be able to automatically create all the distribution binaries, automating everything from unpacking and patching the sources to compilation, installation and packaging. After getting a basic ebuild prototype working, I started creating ebuild scripts for the key components of a Linux distribution (like gcc, glibc, binutils, util-linux, and friends). My Stampede development box was gradually turning into my own system, as I redesigned the initialization scripts (basing them on the Stampede initialization scripts that I had previously designed) and testing and installing every new package that I created. A few months later I had a complete, self-hosted Linux distribution. I named it Enoch and sat back and smiled contentedly. But what became of Enoch, and how did Gentoo Linux evolve? Join me in my next article as I tell the story of how Enoch became Gentoo Linux, and the many new challenges I faced along the way. |
'Linux' 카테고리의 다른 글
| The GNU Manifesto (0) | 2006.09.16 |
|---|---|
| GNU 선언문(The GNU Manifesto) (0) | 2006.09.16 |
| Gentoo Linux 배포판의 탄생 (0) | 2006.09.16 |
| Making the distribution, Part 3. The author strays from Linux and then returns (0) | 2006.09.16 |
| Making the distribution, Part 2. From Enoch to Gentoo, via minor setbacks and corporate run-ins (0) | 2006.09.16 |
