사내 상용 솔루션을 위한 빌드

by

제가 다니고 있는 회사에서는 조엘식 분류에서 “사내 소프트웨어”에 들어가는, 중규모 솔루션을 주로 만듭니다. 고객사에서 원하는 대로 플랫폼도 바뀌고, 소스 1줄을 수정하려고 해도 고객사에 작업내역서를 보내고 승인받은 뒤에 직접 들어가서 작업을 해야하는데다가 일요일 새벽에만 작업이 가능한 곳도 있고, 문제가 생기면 손해배상도 들어오고 그러다보니, 아무래도 디펜던시가 우찌됐건간에 시스템 기본 라이브러리를 빼고는 모두 직접 옵션 조절해서 컴파일한 것을 깔게 됩니다. 리눅스에서만 돌던 소프트웨어를 갑자기 AIX에서 돌려보자고 하루 전에 연락이 오기도 하고 -_-; 하여간~ 흐흐

그냥 빌드해 놓고 그냥 tar을 들고 댕기던 시절에는, 빌드도 다 손으로 해야하다보니, 밤마다 자동빌드는 커녕, 업그레이드 한번 하려고 해도, 수시간씩 걸리고, 새 플랫폼이 나와도 포팅하는데 하루종일 별의 별 삽질을 다 하게 됩니다. 그래서, 상태를 좀 개선해 보고자 새로 하는 프로젝트에서는, POSIX 플랫폼이면 무난하게 돌아가는 형태의 빌드를 구성해 봤습니다. 흐흐흐.

처음엔 GNU make 기반의 makefile 문법으로 하려고 했었는데, GNU make에서는 for루프와, target 함수 같은 것을 제공하지 않아서, 아무래도 m4같은 것의 도움 없이는 10개 이상의 디펜던시가 있는 패키지를 모두 한꺼번에 빌드하는 게 꽤 힘들었습니다. 그래서 결국은 NetBSD pkgsrc에서 BSD make를 가져다가 자동 빌드하고 그걸로 프로젝트를 빌드하는 방식으로 바꿨는데.. 이러쿵 저러쿵 만들다 보니까 결국은 포트같이 돼 버렸습니다. 그러니까.. 으흐흐. 예를 들면 이렇게~

요걸로 프로젝트를 매일 밤과 점심시간에 자동으로 빌드해서 에러가 나면 메일로 알려주도록 세팅해 두었습니다. 이제 기능을 좀 추가해서, 바이너리 인스톨러 스냅샷 만드는 것과 인스톨 스크립트로 자동으로 인스톨해서 유닛테스트 돌리는 것도 해보려고 합니당. 지금까지 만든 것은 여기에 올려 두었습니다. 디펜던시도 많고 플랫폼도 많은 내부 프로젝트 관리하는 분은 써 보세요. 🙂

OpenSolaris CDDL의 개요

by

주의: 이 글은 개인적인 해석이며 법적인 정확성을 보증하지 않습니다. 구체적인 저작권, 특허, 상표권에 대한 문제는 원문을 참조하세요.

어제 공개된 OpenSolaris
소스를 보다 보니, 생각보다 재미있고 뜯어 쓸만한 부분이 꽤 많이
있었습니다. 🙂 그래서, 이제 열심히 갖다가 썼는데 뒷통수 맞는
일이 없도록 라이선스인
CDDL (Common Development and Distribution License)을 자세히
읽어보았습니다.

CDDL은 우선 전체적으로 GPL같이 아주 딱딱하게 조절된 무서운
어조로 써 있지 않고, 그냥 통상적이고 상식적인 수준의 문장으로
되어 있어서 읽기가 편하다는 면에서는 좋군요. 분량도 애플 것에
비해서 짧고.. 🙂 우선, 첫 부분의 용어 정의 부분에서는 대부분
상식적인 용어와 비슷한데, 몇가지 다른 것이 있다면 이 정도가..

  • “Executable”: 소프트웨어에서 소스를 제외한 모든 파일
  • “Larger Work”: CDDL하에 있는 작업외에 다른 라이선스로 된 큰 작업을
    조합한 작업

CDDL에서는 독특하게 최초 개발자(Initial Developer)와
기여자(Contributor)를 명시적으로 구분해서 권한을 따로 정의하고
있는데, 재라이선싱 권한 외에는 크게 다른 점은 없어보이는군요.
그리고, 다른 라이선스들 (특히 GPL)에서는 특허와 관련된 말들은
최대한 언급을 삼가하고 있는데, CDDL에서는 라이선스 하에 있는
소스를 작성한 모든 기여자들과 최초 개발자들 사이의 특허 문제까지도
명확하게 정의해서, 모호함을 없앴다는 점은 장점으로 꼽힐 수도
있겠습니다.

우선, BSDL과 GPL, Artistic License같은 오픈소스 라이선스 분파들을
서로 비교할 때 사용되는 여러가지 일반적인 특징은 배포, 수정, 판매
등의 다른 조건들은 비슷하지만 라이선스를 동의하는 조건이 조금씩 다른데,
CDDL에서는 이런 조건들을 걸고 있습니다.

  • 소스코드 같이 배포: “Executable” 상태 (즉, 소스 코드가
    아닌 모든 포맷)로 배포를 할 때에는 항상 소스 코드를 CDDL하에
    배포를 해야 한다는 강제 조건이 있습니다. 즉, 이 부분에 대해서는
    GPL과 여러모로 유사한 면이 있다고 볼 수 있습니다.
  • 변경: 원래 CDDL하에 있는 소스를 변경한 부분에 대해서는
    모두 CDDL의 영향 하에 가도록 되어 있으며, 변경자는 그 작업 부분이
    자기 고유 작업임을 밝혀야합니다.
  • 변경 고지: CDDL하에 있는 소스를 변경한 사람은 반드시
    자기가 변경했다고 기여자 목록에 표시를 해야합니다. 기존의 다른
    오픈소스 라이선스들은 이 부분에 대해서, 반드시 고지해야된다는
    얘기는 따로 안 써있는 것들이 대부분이었는데, 원래 소스에서 변경된
    것을 원 저자가 만든 것처럼 표시되는 것을 막기 위해서 넣은 부분인
    듯 합니다.
  • 추가적인 사항: 다른 오픈소스 라이선스들은 호환되는
    것들에 대해서는 추가적으로 다른 라이선스를 적용할 수도 있게 되어있는데
    CDDL에서도 품질보증이나 추가 제공같은 것들을 추가로 넣을 수는 있지만
    이것들이 원래 CDDL에서 보장되는 것들을 해쳐서는 안 되며, 원저자와
    원기여자들이 품질보증이나 추가 제공에 전혀 관련이 없다는 것을
    명시적으로 표시해야합니다.
  • 바이너리 배포: 소스코드가 아닌 형태로 배포하는 경우
    CDDL이 아닌 완전히 새로운 라이선스로 배포도 가능합니다. 즉,
    xchat처럼 소스는 GPL이고, 바이너리만 상용이고 이런 것도 충분히
    가능하다는 얘기겠죠. 단, 이 경우에도 라이선스를 받은 사람은
    소스를 요구해서 CDDL하의 소스를 받을 수 있습니다. 🙂
  • “Larger Work”: 다른 큰 소프트웨어와 섞이는 경우, 예를
    들면 openssl과 apr을 이용해서 mod_ssl같은 게 나오는 것 같은 경우가
    되겠죠. 이런 경우 섞임으로 인해서 최종 생산물이 CDDL을 침해해서는
    안 된다는 확인이 있어야 합니다.

그리고, 예전에 애플에서 한번 시도해서 문제가 되었던, 라이선스
개정시 조건도 같이 업그레이드라는 그런 것은 좀 더 자유롭게 되어서,
썬에서 라이선스를 개정하더라도, 처음 소프트웨어를 받을 당시의
CDDL 버전을 쓸 수 있습니다.

재배포를 하는 경우 반드시 소스코드를 배포해야 한다는 점에서,
BSD에서는 /usr/src/gnu/ 디렉토리에나 들어갈 만한 라이선스라
좀 섭섭하기는 하네요. 으흐흐. 그래도 뭐 썬도 먹고 살아야~ -O-

오픈솔라리스 공개

by

그동안 거의 베이퍼웨어 수준으로 뜸을 들이고 있던 OpenSolaris가 드디어 소스를 공개했군요. 타이틀 화면의 “열린”이 아주 멋있습니다. 🙂

bz2로 압축해서 44메가 정도되는 솔라리스 소스 중에서 가장 기대하고 있던 부분인 iconv소스를 얼른 쳐다 봤습니다. 🙂 솔라리스의 iconv는 다른 iconv와는 달리, 변환 루틴부분을 위한 별도의 언어를 정의한 뒤에, 그 소스를 C로 컴파일하는 구조로 되어있어서 확장에 매우 유리하게 되어있는데, 현재 아주 구리구리한 구조로 되어있는 FreeBSD iconv를 고치는데 이런 방향으로 해 보면 도움이 될 것 같습니다. 소스를 뒤져보니까 usr/src/cmd/geniconvtbl/ 안에 메타언어 컴파일러가 들어있고, libc 소스 안에 iconv가 들어있는 간단한 구조로 되어있는데, 소스 구성이나 레이아웃 등이 BSD와 크게 다르지 않은 편이라 앞으로 좋은 장난감이 될 것 같군요.

iconv외에도 gettext나 멀티바이트 API 같은 FreeBSD가 약한 부분들 뜯어다 쓰기에 요긴할 것 같은데.. 라이선스가 FreeBSD에서 섞일 수 있는 것으로 판단이 될지 좀 두고 봐야겠네요..

기민한 언어의 날 – 아직은 그냥 생각

by

일본에서 여러 해 이어오고 있는 LightWeight Languages Weekend를 보면서, 우리나라도 따로따로 하면 썰렁한 언어들을 묶어서 뭔가 시너지가 날 수 있는 것 해 보면 좋겠다! 하고 생각해 오고 있었습니다. 요새 다른 분들도 가끔 그런 것 있으면 좋겠다 말씀도 하시고, 한국소프트웨어진흥원에서도 일정 수준 지원이 가능하다고 의견을 주셔서 슬슬 준비해볼까 하고 버스에서 곰곰히 생각해 보고 있습니다. 🙂

아무래도, 한국에서는 PHP의 시장 점유가 엄청나게 높은 편이니, LightWeight 언어라고 하더라도 PHP는 규모가 맞지 않아 포함하지 않는 것이 좋을 것같고, 멋진 친구 승범군이 운영하는 Squeak모임도 생각나고 해서, LightWeight보다는 기민한 언어(Agile Language)로 하면 어떨까 하고 생각이 났습니다. 흐흐 그래서, 대략 Python, Perl6/Parrot, Ruby가 기간이 되고, Squeak이나 Lua, Groovy 같은 약간 다른 성격의 언어들도 가능하다면 포함이 될 수 있으면 좋을 것 같습니다.

일단, 여러 언어가 모여서 행사를 하는 것이 시너지를 내기 위해서는, 일부 언어는 알고 있지만, 아직 자세히는 모르는 다른 언어들의 특징을 느껴볼 수 있도록 주제가 너무 특정 기술에 치우치거나 기초 문법에 치중한 것은 안 될것 같다는 생각이 듭니다. 그리고, 서로의 의견을 자유롭게 교환할 수 있도록 분야별 BoF 세션 (예를 들면, TwistedWeb/Nevow와 Ruby on Rails등을 주제로한 WWW BoF나, 각 언어 간의 메타클래스 특성을 활용 아이디어들을 교환하는 세션같은..)도 공식적으로 시간을 잡거나 PyCon에서 하는 것처럼 아무데나 복도에 퍼질러 앉아서 시간 가는 줄 모르고 토론하는 것도 좋을 것 같구요. 🙂

파이썬마을의 순식간에 뚝딱하는 세미나들하고는 좀 다르게 미리 스티어링 그룹도 구성을 하고, 각 세션들에 대해서는 Call for Paper를 통해 공개적으로 발표하실 분을 모집해서 알차게 꾸몄으면 하는 생각이 있습니다. 아직은 그냥 저 혼자 출퇴근길에 버스에서 생각하는 아이디어에 불과한데, 앞으로 다른 여러분들께 연락을 드려서 진행을 해봐야겠습니다~

근막염의 습격

by

ㄱ자 책상에 기대서 일하는 자세의 특성상 지난 몇년간 왼팔꿈치 주변 관절이 좀 삐걱댄다는 느낌은 좀 있어왔습니다. 그런데, 급기야 지난주부터는 팔 안쪽 근육이 막 뜨겁게 달아오르고, 출근하고 3시간 정도가 지나면 막 근육들이 땡겨서 키보드를 도저히 못 칠 지경에 이르러서.. 우일님의 추천으로 집 앞에 있는 신경통증전문 제통의원을 찾아갔습니다.

대충 간단한 진잔으로 여기저기 근육을 꾹~꾹~ 눌러보더니 근막염이라고 합니다. 흐흐. 사실 뭐 전날 약간 증상을 네이버kin에서 찾아보니까 근막염 비슷한 것 같기는 했는데.. 빙고~ 그래서 1시간 정도 물리치료를 받았는데, 찜질하고 안마를 받았습니다. 찜질은 별로 새로울 것은 없었는데, 전동 안마기는 TV에서 볼 때에는 저게 과연 간지럽히기나 할 수 있을까 했는데, 헛.. 그 진동이란..;; 제 세팅은 100~120Hz에 A,B 채널 모두 level 2였는데도 막 팔이 덜렁덜렁 거릴 정도로 안마가 되는군요.. 흐흐 신기~ level 끝까지 올렸다가는 완전 난리 나겠어요 -.-;;

물리치료 받는 도중에, 옆 치료실에서 나는 소리를 들었는데.. 근육에 주사맞는 아줌마의 “흐어어어어어~” 신음소리나.. 침맞으면서 계속 헉헉대는 아저씨나.. 여러모로 저 정도는 아니라 다행이구나 생각이 자주 들더군요. 으흐.. 역시 치료과목때문에, 할머니, 할아버지가 많이 계셨는데, 뭔가 자주 가면 엄살부리는 것 같은 느낌도 들고 그렇네요 ==;;;

하여간, 결국 약 처방도 받고 나왔습니다. 지난 번에 이비인후과에서 항생제를 잔뜩 주는 바람에 막 쓰러지고 고생한 경험이 있어서, 처방전을 우선 약국에 가기 전에 구글로 자세히 분석을 해 봤습니다. 처방 내용이 “에어탈정”이라는 비스테로이드성 소염진통제, “버클리정”이라는 골격근이완제, “가스모틴정”이라는 진경제가 나왔는데, 다행히도 심각한 부작용요인이나 항생제는 없더군요. 으흐흐~ 다행~ 그런데, 버클리정이라는 것은 왠지 BSD랑 친한 것 같아서, 이름을 찾아봤는데 인터넷에서도 정보가 막 사라지는 분위기이더니, 결국 약국에서도 없다고 해서 다른 회사의 근육이완제로 바꿔서 받았습니다. (꼭 항목이 딱 맞을 필요는 없는 모양 -ㅅ-;)

그래서 이제 밤이 되니까, 어제보다 훨씬 나아진 것이.. 기분이 좋군요. 🙂 내일부터는 왼팔도 그런대로 쓸 수 있을 것 같고… 신나네용 푸흐.. 자세를 똑바로 합시다.. ㅠ.ㅠ 이제 일자 책상으로 바꿔야지~

FreeBSD 최근 소식

by

요새 여러모로 일이 많아서 좀 바빠서 메일을 통 못 읽다가, 밀린 CVS 메일을 보다보니 재미있는 게 여러개 있군요.. 🙂

구글 Summer of Code 프로젝트
구글 Summer of Code에 FreeBSD가 멘터로 활동할 여러가지 주제들이 목록으로 정리되어 올라왔습니다. Xen지원이나 BSD Installer 통합, CVSUp을 C로 재작성하는 일, UFS 저널링 지원 추가 같은 것들이 매우 흥미로워 보입니다. 🙂 저는 개인적으로는 BSD iconv를 유저랜드에 통합하고 kiconv에 DBCS/SBCS 외에 가변 바이트 지원을 추가하는 작업에 관심이 많은데 학생이 아니라 참가도 못하고~ 병특 끝나기 전이라 시간도 없을 것 같고~ 이히히;

WPA 클라이언트 베이스로
BSD 할아버지들 중에서 가장 활발한 활동을 하고 있는 샘 아저씨가 드디어 WPA 지원을 베이스에 넣었습니다. 🙂 이름은 wpa_supplicant입니당. EAP-TTLS까지도 언급이 되어 있는 걸 봐서 아직 써보지는 않았지만 매우 기대가 되는군요. 🙂

ISC dhclient에서 OpenBSD dhclient로 교체
FreeBSD에서 오랫동안 쓰던 ISC dhcpd에 포함되어 있는 dhclient를 이제 OpenBSD의 dhclient로 교체하였습니다. contrib이 아니라 그냥 베이스에 머지해버릴 정도로 강한 애착이.. 흐;

Kip Macy가 커미터로~
FreeBSD로 Xen을 포팅하는 작업을 오랫동안 열심히 추진하던 Kip Macy가 그동안 그 분야를 잘 아는 커미터가 없는 통에 커밋권한을 못 얻고 있다가 최근에 드디어 소스 커미터로 들어오게 되었습니다. 드디어 FreeBSD도 Xen의 문명 혜택을 받게 되겠군요. ^.^

므해해해

FreeBSD 6.0 코드 프리즈 임박

by

FreeBSD 6.0 릴리스를 위한 오랫동안의 열띤 토론 끝에, 이제 다음 주에 코드 프리즈가 시작됩니다. 구체적인 일정은 다음과 같이 잡혀 있는데, 물론 실제로 진행되다가 복병을 만나면 좀 늦어지겠죠. 🙂

  • 2005년 6월 10일: 피쳐 프리즈, 코드 슬러시 (약한 프리즈)
  • 2005년 7월 10일: RELENG_6 브랜치 (여기부터는 releng팀 승인이 있어야 커밋 가능)
  • 2005년 8월 1일: RELENG_6_0 브랜치 (6.0 릴리스 브랜치)
  • 2005년 8월 15일: FreeBSD 6.0 릴리스

광복절 기념 릴리스인가 보군요. 🙂

우울증의 인지치료

by


우울증에 대해서 좀 더 깊숙히 알아보고자, 우울증 치료에 관한 책을 샀습니다. 우울증에 대한 책은 서점에 정말 많이 있긴 했는데, 수필집쪽에 꽂혀있는 것들은 너무 피상적이고 다 극복한 사람들이 올챙이적 시절 모르듯 긍정적으로만 접근하고 있어서 이해가 된다기보다는 그냥 그런것도 있구나 정도 밖에는 볼 수가 없었습니다. 그래서 심리학쪽에 꽂혀있는 책들을 봤는데, 대체로 한 주제에 너무 집중해서 깊숙히 파고 있거나, 이상심리학 전체를 다루는 바람에 우울증 부분이 적거나 그런 편이라서, 적당한 것이 마땅히 없었는데 이 책은 적당히 원인과 현상, 치료 기법 등에 대하여 설명하고 있는 점이 괜찮았습니다. 🙂 저자의 성이 Kent Beck과 같다는 점도.. ^_^

소프트웨어를 주로 하는 프로그래머들은 직업 특성상 늘상 별 이유없이 낙천적인 경우가 많기 때문에, 우울증이 뭔지 잘 모르고 그냥 에러가 많이 났는데 잡을 시간이 없어서 우울한 것이나 비슷한 것으로 생각하기가 십상입니다. (물론 저도~) 그렇지만, 이 책에서 설명하는 것을 읽어보니 우울증은 그냥 에러 잡기 귀찮은 그런 것과는 좀 다른, 사고 과정 상의 연쇄작용으로 일어나는 복잡한 현상인 것이었습니다. 즉, 우울증이란 그냥 기분이 나쁜 상태라기보다는, 한가지 또는 여러가지의 자기에게 일어난 문제를 지나치게 확대하거나 다른 것을 잊어버린 채로 그런 문제점에 집중하거나, 부정적인 사고를 연속적으로 해서 결국은 왜곡된 심리에 휘말리는 사고 과정 같은 것이 계속 반복되어 객관적인 시각에서 자신을 보지 못하는 상태를 얘기하는 듯 합니다.

처음 시작은 아주 사소하게 자기가 빨래를 했는데 실수로 돈을 안 꺼내고 빨아서 1000원을 못 쓰게 됐다는 점을 자책하는 것으로 시작해서 그 문제를 확대해서 이 문제 저 문제 다 붙어서 결국은 “난 안돼” “살 가치가 없어” “난 주변사람들에게 해가 될 뿐이야” 정도까지도 발전이 돼서 자살소망단계까지도 갈 수 있다고 합니다. 물론 이런 일들을 객관적인 시각에서 보면 말이 안 되지만, 사고 단계마다 비약이나 왜곡을 약간씩만 더한다면 여러 단계가 거치면 그렇게 생각이 진행될 수도 있구나 하고 책의 예제를 보고 감정이입을 해 보니까 저도 그렇게 생각할 수도 있을 것 같네요.

여러가지 사고적인 것 뿐만 아니라, 우울증은 생리적인 문제로 인해 발생되기도 하는데, 시냅스간의 신경전달 물질이 부족한 경우, 논리 왜곡이 일어날 확률이 높다고 합니다. 그래서, 감정이 부족한 생활을 하던 사람들이 신경전달 물질의 부족으로 결국은 우울증의 악순환에 들어서는 경우가 많다고 합니다. 이런 경우 신경전달물질을 보충해 주는 리튬제가 상당한 빠른 효과가 있다고 하는데, 약물치료만으로 극복하는 경우에는 다시 비슷한 상황이 온다면 재발할 확률이 높기 때문에 가급적이면 인지적인 치료도 동반되어야 한다고 하는군요.

그래서, 인지적인 치료가 과연 어떤 것인가에 대한 내용이 이 책의 대부분의 내용을 차지하고 있습니다. 인지 치료는 다른 의학들처럼 물리적인 메카니즘을 분석하는 것이 아니라, 환자의 정신적인 사고 과정을 분석해서 악순환을 끊어서 객관적인 사고를 복구할 수 있도록 도와주는 소프트웨어적인 과정입니다.

따라서, 인지 치료에서는 먼저 환자가 왜 그런 사고 과정에 들어가게 되었는지를 주변 사람의 정보와 본인의 정보를 토대로 밝혀낸 다음에, 그 사고 고리를 스스로 반박할 수 있도록 유도하고, 결국은 원래의 생활에 복귀하여서도 그런 사고로 돌아가지 않도록 스스로 대처할 수 있는 여러가지 논리 기법을 숙련시켜 주는 것이 주가 되는 것 같네요. (책 안에서는 많은 우울증 환자들의 경우를 예시로 치료기법들을 설명해 놓았습니다.)

그런데, 우울증 치료에 있어서 주변 사람들이나 치료자의 대응이 기존의 상식과는 다른 점이 꽤 많이 있었는데, 예를 들면 환자에게 주변 사람들이 이유없이 게속 잘 해주려고 하는 것 또한 자책감으로 인한 우울증 환자에게는 “난 주변사람들에게 짐이 될 뿐이야”같은 심리를 자극해서 더 악화되게 만들 수도 있다고 하고, 환자의 상황을 파악하기 위해서 이런 저런 질문을 너무 많이 하다보면 자기 상황에 대한 수치심으로 또 악화되고.. 이런 상황이 여러가지 있다고 합니다. 즉, 우울증 환자를 접할 때에는 항상 자신의 행동이 오해를 불러일으킬 소지가 있는지 여러모로 생각해 보고 불명확한 해석이 있을 수 있는 부분에 대해서는 오해하지 않도록 부연 행동이나 설명을 해 주도록 명시적 행동이 필요하다고 합니다. 또 그런 행동이 너무 티가 나면 안 되겠죠~

현대 사회에서는 점점 사람과 사람 사이가 어떤 면에서는 고립되어 가고, 개인적인 시간이 늘어나면서 우울증이 뚜렷하게 증가하고 있다고 합니다. 우울증도 다른 것들과 마찬가지로 초기에 잡으면, 주변의 도움으로 어려운 경험없이 쉽게 잡을 수 있다고 합니다. 미리미리 공부해서 명랑 사회 만들어 나갑시다. -O-

조엘이 말하는 C를 배워야 하는 이유

by

최근에 화장실에서 힘쓰면서 읽을 책으로 조엘 온 소프트웨어 한국어판을 사서 읽다가, 조엘이 프로그래머는 C를 배워야한다고 주장에 대한 근거를 읽었습니다. (상당히 앞쪽에 있는데, 웹에서는 못 읽어봤었네용 므흐흐;)

전산과 신입생은 CPU부터 시작해서 C를 활용하는 데까지 차곡차곡 기초를 닦아야 합니다. 저는 솔직히 너무나도 많은 컴퓨터 관련 교육과정들이 자바가 가장 좋은 초보자용 언어라고 선전하는 현실에 질려 버렸습니다. 흔히 자바는 쉽고, 따분한 문자열이나 malloc과 같은 골칫덩어리를 다루는 과정에서 혼란을 겪지 않으며, 아주 큰 프로그램을 모듈로 나눠서 만들 수 있는 근사한 객체지향 프로그래밍 기법을 배울 수 있다는 화려한 이유들이 따라 나옵니다. 하지만 여기에는 교육적인 재앙이 있습니다. 졸업생들은 하향 평준화돼 러시아 페인트공 알고리즘을 여기저기에 만들어내며, 심지어 자신의 잘못을 인식조차 못할 겁니다. 펄 스크립트에서 이런 사실을 결코 볼 수 없을지라도, (물론 어렵지만) 기본적으로 문자열이 무엇인지 아주 깊은 단계에서 이해하지 못하기 때문입니다. 다른 이들이 뭔가를 잘하도록 가르치길 원한다면, 기초부터 시작해야 합니다. 이는 마치 태권소년과 비슷합니다. 마루바닥을 쓸고 닦고 쓸고 닦고, 이렇게 3주만 하면, 자연스럽게 목표물을 향해 발이 쭉쭉 뻗어나갑니다.

— 조엘 온 소프트웨어 (조엘 스폴스키)

참고: 여기서 “러시아 페인트공”이란 이 문단 앞에서 설명하던 O(N²) 알고리즘을 뜻합니다.

그동안 C를 모르고 하이레벨의 언어들만 다루는 프로그래머들이 흔히 오해하는 것들을 보면서, 기초를 위해서는 C가 아무래도 필요하지 않겠는가 생각은 해 왔지만, 뭔가 보수적이라는 생각에 아냐아냐 하고 부정도 해 봤었습니다. 그렇지만, 파이썬만 생각해 보더라도, 파이썬만을 아는 프로그래머라면 list.append, list.insert, str.__add__ 같은 것들이 사실 상 atomic operation처럼 느껴지기 때문에, 하부에서 일어나는 일을 일일이 달달 외우지 않고서는 쉽게 추측하기가 힘듭니다. 그 때문에, 결국은 비슷한 노력으로 코드를 짜더라도, C도 같이 하는 개발자들에 비해 훨씬 비효율적인 코드를 짜기가 일쑤입니다.

그런 면에서, 아무래도 입문은 자바나 파이썬 같은 언어로 하더라도, 결국은 바다 위에서 동동 떠다니지 않고 어딘가에 닻을 단단히 매서 흔들리지 않는 코드를 위해서는 C 같은 저수준의 언어를 배워야 한다는 것이 피할 수 없다고 생각됩니다. 같은 맥락에서 예전부터 매우 좋아했던 Larry Wall의 명언이 하나 생각납니다. 🙂

Real programmers can write assembly code in any language.
— Larry Wall

그래서 젊은 나이에 벌써 저수준과 고수준을 종횡무진하는 토끼군이나 디토군같은 분들을 보면 참 우리나라의 미래가 밝다고 느껴집니다. 🙂

젠투에서도 py-freebsd를 사용합니다

by

엊그제 Gentoo/FreeBSD 프로젝트 개발자 중의 한 명이 제게 메일을 보내 왔습니다. 그 내용은 Gentoo의 패키지 관리 툴이 아무래도 파이썬으로 되어 있다보니 파이썬으로 대체로 다 만들어야 하는데, 리눅스에는 없고 FreeBSD에만 있는 파일의 chflags 속성 관리를 위해서 원래는 자기들이 직접 패치한 것을 쓰고 있었는데, py-freebsd가 좋아서 바꿔보려고 한다는 말이었습니다. 🙂

뭐 다른 것은 다 괜찮은데, os.stat()에서 st_flags를 읽어오고 싶은데, 파이썬에서 제공을 하지 않는 속성이다보니 참 애매한 상황이라 이를 py-freebsd에서 제공해 달라는 것인데, 가만 생각해보니 py-freebsd에서 지원해 줄 수도 있겠지만 지원하게 되면 소스가 상당히 지저분해질 것 같아서 그냥 파이썬을 고쳐서 커밋해 주고, 그것 백포트 해서 쓰라고 답장을 보내버렸습니다. ;;

이제 Gentoo 소스에 import freebsd 없나 잘 봐 보세용. 이히히 =3=33