대안언어축제 2006 기획

작년에 대단한 반향을(스스로 생각하기엔 ㅋㅋ;;) 일으켰던 대안언어축제 2회를 올해 여름에 다시 개최하고자 하는 움직임이 일고 있습니다. 이번에는 일본의 LLDN이나 다른 컨퍼런스 들에서 얻은 새로운 아이디어들을 더 모아서, 더욱 더 신선하고 재미있는 컨퍼런스가 되면 좋겠네요. +_+

우선은, 지난 번에 대안언어축제이기는 했지만, 언어교환의 측면에서 약간 부족했던 면을 보완하기 위해서, 각 언어별 튜토리얼 세션을 공식 세션으로 넣기로 하였습니다. 언어별 튜토리얼 세션을 물론 각 언어별로 따로 따로 하면 상당히 식상하고 졸리기 때문에 비슷한 언어 몇 가지를 묶거나 전혀 다른 언어 몇 개씩을 묶어서 각 언어의 구루들이 패널로 참가하여, 비교언어학이나 인지언어학을 공부할 때처럼 각 언어의 meme을 느낄 수 있는 통합적인 튜토리얼 세션이 되면 좋겠습니다.

그리고, 참가자 간의 활발한 교류가 지난 번에는 의도대로 잘 되지가 않았는데, 아무래도 일정이 빡빡하고, 자봉과 통사들의 회고에서 행사 처음에 참가자간의 사회화를 덜 했기 때문에 그런 것 같다는 짐작을 했습니다. 그래서, 이번에는 아무래도 축제로써의 의의를 강화하기 위해서, 초기부터 교류를 활발하게 할 수 있도록 일정 진행에 여유를 많이 두고 재미있는 야외활동이나 놀이 같은 것을 많이 넣으면 좋을 것 같네요. 요새도 창준형이 재미있는 놀이를 많이 개발했다고 합니다. ^_^

인기에 힘입어 결국 독립 행사로도 치뤄진 코드레이스는 좀 더 확실한 준비와 완벽한 장비 세팅으로 매끄러운 진행이 이뤄지면 분위기를 확 띄우는 좋은 계기가 될 듯 합니다.

요새는 우리나라 개발자 커뮤니티들이 확실히 부흥기를 맞고 있는 느낌이 많이 듭니다. 대안언어축제 2회에도 많은 분들의 능동적인 참여가 있어서 세계에 수출하는(;;) 좋은 행사가 되었으면 합니다. 🙂 7,8월에 활동 할 수 있는 시간이 많으신 분들은 자봉으로 활동하시면 더욱 더 보람을 느끼실 수 있을 것 같고, 자신의 언어를 소개하고 싶은 분들도 여러 세션들을 맡아서 해 주시면 좋겠고~ 자세한 일정이나 계획은 다음에 좀 더 잡히는 대로 알려드리겠습니다.

오픈소스는 어떻게 먹고 사는가?

오늘은 두 번째로, “오픈소스는 어떻게 먹고 사는가? (podcast)“에 대해서.. 🙂 — 휴대용 mp3 플레이어가 있는 분은 오른쪽에 있는 RSS 아이콘을 눌러서 iTunes 같은 걸로 받아서 들으시면 더욱 좋습니다. -O-

오픈소스 개발자들은 주로 어떤 회사에서 일하고, 회사들은 오픈소스를 하면서 과연 어떤 방법으로 먹고 살까에 대해서 대표적인 사례들과 패턴 몇 가지를 소개해 드립니다. 자세한 내용은… (생략) -ㅇ-;;; 이거 아무래도 서투른데다가 말로 하다보니 편집이 쉽지가 않아서, 틀린 말도 있는데 그냥 남겨두게 되었네요.. 다음에 글로 깔끔하게 정리를.. 크흐;

나중에 녹음된 것을 듣다보니, 오픈소스가 꼭 열역학 제 2법칙처럼, 장시간, 큰 규모에 더욱 잘 적용이 되는 것 같은 느낌이 드는데.. 작은 규모에서는 어떻게 시작할 수 있는가를 다음 주제로 한 번 잡아 보겠습니다. ^^;

최근 얼마 간의 데이터 쌓기

예전에 회사에서 일할 때, 초당 30만건 정도 들어오는 자료의 빈도를 세서 누적 데이터를 기준으로 5분, 1시간, 1일, 1주, 1달, 1년 최다 순서로 100개 정도씩을 보여주는 루틴을 만들 일이 있었습니다. 그 때는 뭐 회사 프로젝트도 검수 기간도 다 끝나고 영 제값 못 받고 한다고 생각하는 프로젝트였기 때문에, 그냥 대충 가장 단순하게 막 구현을 했더니 오방 느려서 하드웨어빨로 버티고 있었습니다. 나중에는 각 샘플링 별로 상위 10배수를 뽑아서 나머지를 버리는 등의 튜닝을 약간 해서, 처리속도가 데이터 들어오는 것을 못 따라가는 문제를 약간 해결해야하긴 했습니다. 🙂

물론 이렇게 하면, 정확한 이산 데이터를 합해서 하기 때문에 아주 정확한 자료를 얻을 수 있다는 장점은 있지만, 통계 기간에 들어가는 샘플의 수가 워낙 많기 때문에 속도의 문제나 기간의 제한 등 여러가지 문제가 산적해 있었습니다. 특히 가장 문제는, 샘플 저장 수를 줄이기 위해서 장기간의 통계용 샘플들은 정밀도를 줄여서 5분 데이터를 모두 모아서 1시간 데이터로 만드는 등의 작업을 거치기 때문에, 업데이트가 바로바로 되지 않는 문제가 있었습니다. 그래서, 그때는 그냥 뭐 병특도 끝나가고 해서 대충 넘어 갔는데 -ㅇ-, 얼마전에 여자친구 숙제를 도와주다가, 커널에서 load average 계산하는 방법을 보고서 이것을 게시판의 “최근 뜨거운 글 100개 목록”이나, 네트워크 장비들의 “최근 다발 접속 IP 100개” 같은 통계에 쓰면 좋겠다는 생각이 들었습니다. +_+ 벌써 다른 데서는 다 쓰고 있었는지도 모르겠지만; 이렇게 되면 보통 하듯이 하루 단위로 리셋되지 않고 부드럽게 꾸준히 업데이트되기 때문에 비교적 부하를 줄이면서도 쓸만한 데이터를 얻을 수 있지 않을까 싶네요~

그래서, 그 방법이 무엇이냐!
간단히 요약해서 다음 수식으로~

커널 소스코드에서는 sys/kern/kern_synch.c 부분에 있습니다.
x가 로드이고, s가 새로 들어오는 샘플, window가 원하는 통계 기간의 샘플 수 입니다. 이렇게 하게 되면, 새로 들어오는 샘플은 1-1/exp(1/window) 의 비율로 들어가고 그 다음부터는 1/exp(1/window)가 계속 곱해져서 살짜쿵씩 사그라듭니다. 적당히 원하는 보존 기간을 지나가면 무시할 수 있을 만큼의 비율로 없어지기 때문에, 데이터 값 1개만 유지하고서도 이산형 데이터 모두를 저장하는 부담을 줄일 수 있다는 점에서 그런대로 쓸만한 방법인 것 같네요. +_+

그래서, 과연 이 놈이 진짜로는 어떻게 없어지나 그래프를 한 번 그려 봤습니다. (x 축이 축적 횟수, y축이 최종 데이터의 반영 비율, 샘플 누적 목표는 10으로 했을 때)

그래서 대략 계산해 보면, 10개까지의 데이터들의 반영 비율이 63% 정도 되고, 2배수인 20개까지의 비율의 합이 86%정도 됩니다.
정확한 데이터는 아니지만, 데이터 계산을 연속적으로 할 수 있고 연산/저장량이 많이 줄어든다는 점이 장점이겠습니다.

그런데, 커널에서는 부동소수점 연산을 피하기 때문에, 이런 계산을 좀 더 재미있는 방법으로 하고 있는데, 이것도 한 번 눈여겨 볼 만합니다. 🙂 커널 소스의 cexp라는 fixpt_t형 배열에는 exp(-1/샘플수)의 값이 미리 계산이 되어 있어서 그냥 곱하기만 하면 되게 되어있기 때문에 e 계산이나 나누기를 하지 않아도 됩니다. 그리고, 사실은 이놈이 부동소수점형이 아니라, CPU에서는 정수형으로 취급되는 고정소수점형이라는 것~ 32비트 중에서 왼쪽 21비트를 정수영역, 나머지 11비트를 소수점영역으로 쓰는데, 1<<11 * 소수 이렇게 하면 간단하게 소수점 이하라도 쉽게 변환이 되고, 덧셈 뺄셈도 생각해 보면 그냥 정수 덧셈,나눗셈 인스트럭션으로 될 것을 알 수 있습니다. 그리고, 곱셈도 가능한데 둘을 곱한 다음에 소수 영역 길이인 11비트만 오른쪽으로 시프트 해주면 고정소수점 곱하기 한 것처럼 됩니다. (물론, 손으로 써보면 쉽게 증명이 됩니다. 🙂 후배한테 자랑했더니 요새는 학교에서 이런 것도 가르쳐 준다는군요 -.-;)

뭐 하여간.. 전에 회사에서 바쁘던 와중에 검색을 할 때는 좋은 아이디어가 딱히 안 떠오르고, 검색을 해 봐도 딱히 좋은 알고리즘이 안 떠올랐는데, 계속 곱하기만 해도 줄어든다는 것을 떠올리지 못한 것은.. 아무래도 수학 공부를 안 해서일까요 -.-a 그래서 이번 학기에 공수 불끈! +_+

파이썬 3000~

으흐흐.. 어제 귀도가 p3yk 브랜치 버전을 3.0으로 올렸습니다.
그래서 이제 3.0이 확~ 다가온 느낌이군요.. ^_^;
(뭔가 꼭 학부 OS 첫 숙제들 같이 버전 고쳐서 컴파일해오기 한 것 같은 기분도 약간 -O-)

아직 텔레파시는 지원 안 합니다. 🙂

파이썬 2.4.3 포트 업데이트 완료

어제 릴리스된 파이썬 2.4.3으로 lang/python 포트를 업데이트 했습니다. 이번에는 얼마 전에 lang/python-devel 포트에서 시험적으로 적용했던 pkg-plist 줄여쓰기를 메인 포트에서도 한 번 적용해 봤습니다. 원래 py, pyc, pyo를 모두 pkg-plist에 적어 두고 있었는데, 용량이 너무 커져서 파이썬 포트들만 모두 합쳐도 이제 1MiB가 넘어가는 판국이 되어서 pyc와 pyo를 빼고 awk로 중간에 처리를 하도록 해버렸더니 60KiB정도가 줄었습니다. 🙂 그리고, NO_NIS는 있으면서도 PORTMAP은 안 끈 시스템에서 설치하다가 파일이 없다고 에러나는 것도 rpcgen 대신 ypcat을 체크하도록 해서 고쳤습니다.

파이썬 2.4.3은 아주 마이너한 버그 패치들만 들어가 있기 때문에, 기능적으로는 특별히 볼 만한 것은 없지만, Coverity와 refleak check, buildbot 등 파이썬 개발팀에서 최근에 사용하기 시작한 완성도 높이기 덕택에, 자잘한 버그들이 정말 많이 수정되었습니다. (예를 들어 PyObject_Unicode(NULL) 하면 세그폴트 나버리는 문제라던지..) 완성도 관련이나 릴리스 자동화, 막판의 버그 픽스와 하위 호환성의 충돌과 관련해서 좀 더 깊숙히 할 얘기가 있는데 2.4.3 릴리스와 관련된 뒷얘기들은 다음 기회에 다시 자세히~

그나저나, 지금 확인해 보니 아직 넷비, 우분투, 젠투, 데비안, 페도라에는 2.4.3이 안 들어간 걸 봐서는 이번엔 프비가 대략 1등? ^_^;; =3=33 (시험 전날 공부는 안 하고 이런거나 –;;)

다음 PyPy Sprint는 도쿄에서

파이썬을 파이썬으로 주로 구현하는 야심찬 프로젝트인 PyPy 프로젝트는 뭔가 계기가 되는 굵직한 작업들이 주로 개발자들이 오프라인에서 모여서 스프린트를 하면 뭉터기로 해결이 되는 특징이 있습니다. 무협 영화에 보면 자주 나오는, 숨어있던 고수들이 어느날 갑자기 여기 저기서 흘러들어와서는 중원의 잡배들을 물리치고, 휙하고 사라지는.. 마치 그런 장면! (.. 괜히 흥분;;) 요즘은 우리나라의 서상현씨와 서지원씨도 참여하고 있어서 무척 흥미로운 프로젝트이지요.

그런데, PyPy 스프린트는 지금까지 거의 유럽에서 하고 가끔 미국에서도 했었는데, 이번에 처음으로 엉뚱하게 도쿄의 “아키하바라”에서 하기로 했다고 한다뇨~ 역시나 일본에서 하는 것이라 지난번 아시아 코드페스트에서 굉장한 지원을 해 주었던 FSIJ (Free Software Initiatives in Japan)에서 지원 해준다뇨~ 일본에 사는 파이썬 해커들 뿐만 아니라 많은 수의 유럽 해커들까지도 지원을 받아서 참가하는 것 같다뇽~ (;;)

게다가 이번 스프린트 주제 1번이 Squeak VM 백엔드에다가 PyPy를 올린다고 하니.. 특히 스퀵이 강세인 일본에서 많은 해커들이 활발히 참여할 것 같아서 무척 재미있을 것 같습니다. 🙂 아 역시 옆에 있는 나라 사람으로써 우리나라에서도 한 번 했으면 싶지만, FSIJ처럼 돈 많이 쓰는 곳이 없어서 약간 아쉽네요. ^_^;

Vim도 구글로!

어제 Vim 개발자 Bram Moolenar가 구글에서 일하게 되었다고 발표하였습니다. 물론 업무 중에 Vim 개발을 일부분 할 수 있도록 했다는데.. 무섭게 오픈소스 인력들을 빨아들이고 있는 구글이 독립 오픈소스 개발자들을 과연 몇 명이나 남겨놓을지 모르겠군요. -O-

Vim은 원래 우간다 어린이들을 도와주세요! 를 하고 있었지만, Bram이 모든 시간을 Vim 개발에 쓰면서 쉬는 동안에는 Bram의 생활비 지원으로 스폰서십이 바뀌었다가, 다시 Bram이 구글로 들어가고 나서부터는 우간다의 키발레 어린이를 돕는 것으로 원래대로 돌아간다고 합니다.

Vim 7에는 FreeBSD에서 EUC 환경에서 문서 끝을 다 깨먹는 버그가 수정되어 있으니 이제 편하게 살 수 있을 것 같아서 기대가 됩니다. 🙂 우간다 어린이들을 도와줘야겠네요;;

파이썬 2.5 미리보기 6편: C API 청소

이번에는 podcast 맛보기용으로 녹음을 한 번 해봤습니다. -O-; iTunes에 등록하실 때는 RSS URL로 http://openlook.org/blog/rss_itunes_xml 를 등록해 주세용.

아하하. 완전 어색하지만 예쁘게 봐 주세요.
==>> 파이썬 2.5 미리보기 6편: C API 청소 (아마도 처음이자 마지막회 -O-)

파이썬 2.5 미리보기 6편: C API 청소 (녹음 내용의 요약)

파이썬 2.5에서는 C API 청소가 약간 있었습니다. 그동안 문제로 지적되어 왔었던 const가 지정되지 않은 API 인터페이스의 문제들과, 크기를 지정하는 타입으로 int에서 Py_ssize_t로 바뀐 것이 대표적입니다.

const 문제는 PyString_FromString 같은 함수들이 문자열을 char *타입으로 받는데, const char*이 아니기 때문에, 일반적인 문자열 상수를 막 던지려면 경고를 피하려고 캐스팅을 해야하는 문제가 있었습니다. 물론 아예 그냥 상수로 선언을 안 하면 data 영역으로 떠서 메모리에 올라올 때 낭비도 있고요.. 그래서 이번에 const가 쫙 달려서 이제 깔끔하게 쓸 수 있게 되었습니다.

그리고, 그동안 크기를 지정하는 타입으로 int를 사용해 왔었는데, 그 때문에 문자열이나 리스트의 길이가 2^31자/개 까지로 제한되어 왔습니다. 이게 64비트 플랫폼에 가면서 문제가 됐는데, 따라서 플랫폼에 맞는 크기 지정 타입으로 내부적으로 Py_ssize_t를 선언해서 쓰기 시작하였습니다. 덕분에 대부분의 타입들이 64비트의 주소 영역을 충분히 활용하게 되었구요~

그런데, 하나 문제가 생겼습니다. API에서 주소 크기가 문제가 되는 경우, 즉 PyArg_ParseTuple 같이 가변인자를 동적으로 읽어오는 경우에 64비트가 올 자리에 32비트가 오고 그러면 포인터가 막 쭉쭉 밀려서 세그폴트가 나게 됩니다. 이 문제를 해결하기 위해서 그냥 디폴트로는 옛날처럼 int 타입하고 최대한 호환되게 남겨두고, PY_SSIZE_T_CLEAN 이라는 매크로를 Python.h가 포함되기 전에 정의가 되어 있으면 z# 같은 포맷까지도 모두 Py_ssize_t를 사용하도록 하였습니다.

파이썬 C API에서 가장 노가다성이 짙어서 과연 얼마나 심심해야 이런 것 할 시간이 날까 하고 생각하고 있었던 청소가 모두 끝난 것이라 무척 상쾌한 릴리스가 될 것 같습니다. 🙂

FreeBSD 6.1 무엇이 바뀌었나~

오랜만에 FreeBSD 관련해서 뭔가를 쓰는군요. ^.^
지금 열심히 릴리스 엔지니어링 막바지 작업이 진행되고 있는
FreeBSD 6.1에 관심이 많으실 듯 합니다. 유명무실했던
5.x대 릴리스를 딪고 일어서서 이제 본격적으로 안정버전 대열로
들어갈 6.1은 FreeBSD의 역사에서 매우 중요한 역할을 할 듯 합니다.

Python Essential Reference 3판 발간

오프라인 파이썬 서적 중 좋은 것을 추천하자면, 프로그래밍 입문자용으로는 당연히
《Python Programming for the Absolute Beginner》
를 추천하겠지만, David Beazley의 책이 막강하게 지키고 있던 기존에 다른 언어를 쓰던 프로그래머들을 위한 것으로는 David Beazley책이 한물간 이후로는 적당한 것이 딱히 없었습니다.

1판에는 귀도가 추천사를 쓰기도 했던 Beazley의 《Python Essential Reference》는 굉장히 간결한 설명으로 이미 다른 언어에서 뿌리를 내리고 있는 사람들이 옆으로 곁가지 치는 식으로 파이썬을 배우기에는 정말 좋은 놈이었습니다. 그런데 파이썬 책들이 갖게되는 공통적인 문제점.. 파이썬 버전이 올라갈 때마다 문법이 계속 새로 나와서 옛날 버전 책을 사기가 굉장히 난감하다는 것 때문에, 2판이 2.1에 맞춰서 나오자 마자 2.2가 나와버린 이후로 역사의 뒤안길로 미뤄져 있었던 것이었습니다. 이번에 드디어 2.4용으로 업데이트가!

Types and Objects in Python이라는 챕터가 샘플로 올라와 있습니다. 보니까 드디어 isinstance도 다루고 있고, 부담없이 추천할 수 있게 되었네요. 🙂 그렇지만.. 이번에도 이 책의 운명은 참 불쌍합니다… 2.5가 곧 나올텐데.. ㅠ.ㅠ