곧 서울에서 열리는 IETF 59번째 회의로 서울이 후끈후끈합니다~ IETF 홈페이지에도 서울 얘기가 굉장히 많이 나오고, Orkut의 IETF 커뮤니티에도 온통 서울에서 뭐 먹고 싶냐~ 서울에서 주의할 점은 뭐냐~ 기왕 놀러간 김에 1주일 더 휴가 즐기다가 오자~ 이런 얘기로 가득하군요. 한편으로 흐뭇~ 하면서도.. 뭔가 IETF 가더라도 할 게 없다는 생각에 헉~ -ㅇ-; Orkut 서울 커뮤니티에도 보니 IETF때문에 방문하는 외국인들이 많이 가입한 것 같네요.

으음. 내일은 IETF 회의때문에 서울에 방문한 itojun님, dugsong님과 lha(@netbsd)님과 국내 BSD개발자들의 모임이 있습니다. 아아 영어가 긴장되기는 하지만 -O-;; 처음으로 외국인 BSD 개발자들을 본다는 생각에 매우 설레는군요

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

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

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

OpenBSD에서 구현된 파이어월인 pf가 FreeBSD에 커밋되었습니다. 편용헌님께서 많은 수고를 하셔서, 국내에서도 많이 알려져 있죠. 이로써 프비는 베이스에 무려 세종류의 파이어월을 갖게 되었습니다. ipfw{,2}와 ipfilter, 그리고 pf!

아직 pf를 안 써봐서 잘은 모르겠지만.. 뭔가 이름이 짧아서(?) 좋아보이는군요; 어쨌건 pf의 임포트를 계기로 ipfw의 Luigi가 아주 불쾌한 듯 답글을 막 올리고 David Malone도 나와서 얘기하는군요.. 으흐흐.. 대체로 ipfw 옹호자가 좀 더 많은 듯 하긴 한데.. 하늘에 태양이 세개 떠 있으니 어떻게 될지~ 흥미진진 합니다 -ㅇ-

그외에, 아시다시피 FreeBSD에는 쓰레드 라이브러리도 세종류가 있는데 libc_r, libpthread, libthr 이 셋은 경쟁관계는 아니지만.. 하여간.. 프비는 3을 좋아하는지도 모릅니다.. (..) 스크립트 언어도 perl, python, ruby이고... 데스크탑도 GNOME, KDE, XFce이고.. (다 끌어 모아서, 억지로 바득바득 우겨봄.. ;; )

아 컴파일러도 세개네요 gcc, icc, TenDRA... (이젠 더 갖다 붙여 볼 게 없다..;; )

FreeBSD JKH (Junior Kernel Hackers list)나 GNOME love day처럼 쥬니어 해커들이 입문하기 위한 도움이나 리스트 같은 것은 막 입문하려는 해커들에게 큰 도움을 주는 것 같습니다. GNOME love day 같은 것은 다른 데서도 앞으로 많이 했으면 좋겠네요.

그런 의미에서 한국어를 쓰는 쥬니어 파이썬 해커들이 해 볼만한 파이썬 해킹꺼리를 좀 정리해 봤습니다. 관심 있으신 분들은 한 번 도전을.. 서너개 정도만 말끔히 처리하면 파이썬 소스가 아주 익숙해지면서 금방 커밋 권한도 얻을 수 있을 것입니다~

• 다국어 식별자(internationalized identifier): 1월에 Martin v. Löwis의 메일에서 나온 아이디어인데, 아직 PEP나 구체적인 스펙이 나오지는 않았습니다. Martin의 의견으로는 tp_dict에 아스키로 인코딩 가능한 경우엔 string, 불가능한 경우에는 유니코드 객체를 집어넣어 버리고 그와 그와 관련된 함수들을 추가하자고 하고 있습니다. 그렇지만, 이렇게 되는 경우에는 u'abcd'와 'abcd'같이 같은 값이 서로 다른 키로 저장될 수도 있고, 일일이 구분해서 갖고와야 하는 수도 있고 해서 하위호환성 문제가 있는데, UTF-8로 저장하는 방법 등 몇가지 다른 처리 방법이 있을 수 있습니다. 파이썬 전체에 다국어 식별자 패치가 들어가면, 한글로 변수이름과 클래스 이름들을 쓸 수 있게 되기 때문에, 비영어권 사용자의 입문에 큰 도움이 될 것입니다. _ 그냥 단순하게 UTF-8만 되게 만들어 놓은 패치는 http://openlook.org/tmp/i18nidentifier.diff 에 있습니다.

• 크로스 컴파일: 848910 에 패치가 올라와 있기는 한데, 2.2.1기준으로 되어있고 무지 오래된 패치라 제대로 돌아가지 않습니다. 특히 ARM이나 PowerQUICC같은 기종에서 파이썬을 쓰시는 분들에서 유용한데, 크로스 컴파일 지원을 넣기 위해서는 일단 pgen 빌드 과정을 호스트와 타겟을 분리해야하고, setup.py에서 크로스 빌드를 약간 특별하게 취급해서 옵션을 넣어줘야합니다.

• collections와 itertools, statistics: itertools는 2.3에 추가되었고, collections와 statistics는 2.4에 들어갈 모듈인데, 세 모듈은 늘상 쓰는 프로그래밍 패턴을 아주 단순화시켜준다는 면에서 매우 매력적입니다. 지금 들어가 있는 것들도 어느정도는 있지만, 자기가 쓰는 다른 패턴들이 더 있다면 추가해 보는 것도 재미있을 것입니다.

• 순파이썬 로캘 지원: 현재 파이썬에서 지원하는 locale과 관련 모듈들은 모두 시스템 로캘에 의존하고 있어서 요즘 엄청난 이슈가 되고 있는 time.strftime 문제처럼 시스템 독립성에 많은 문제가 되고 있습니다. .NET이나 Java처럼 언어 자체 지원으로 로캘을 지원할 수 있다면 플랫폼 독립성에 큰 도움이 되겠죠. 이 문제에 관심이 있으시다면 IBM의 ICU를 참고로 하시면 됩니다.

• CNS-11643, HKSCS지원: 파이썬에 들어가 있는 CJKCodecs는 지금 널리 쓰이는 CJK 인코딩 중에 EUC-TW, ISO2022-CN같은 CNS-11643을 사용하는 인코딩들과 HKSCS의 지원이 빠져있습니다. 잠재적으로 대만과 홍콩 사용자들에게 문제가 될 수 있어서, 언젠가는 지원을 추가해야합니다. 이쪽 인코딩 정보에 대해서도 ICU 소스에 자세히 나와있습니다.

• SCSU 코덱: 파이썬에서는 아직 표준 유니코드 압축 (Standard Compression Scheme for Unicode)을 지원하지 않습니다. 아무래도 UTF-8나 16보다 용량이 훨씬 적게 나오기 때문에, 쓸모가 많습니다~ SCSU도 ICU에 X11라이선스로 된 C 소스가 있습니다.

• UTF-8 코덱 StreamReader.readline 수정: 현재 파이썬 UTF-8, UTF-7코덱의 StreamReader.readline은 전혀 제대로 동작하지 않는 상태입니다. 그런데, 딱히 깨끗한 해결책이 없기때문에 어쩔 수 없이 그냥 놓인 상태인데, 파이썬 코드로 10줄 내외이기때문에, 한번 뛰어들어볼 만 합니다.

• sre모듈 C로 번역: sre모듈 중 일부는 굉장히 속도가 요구되는 부분임에도 불구하고 현재 파이썬으로 구현되어있어서 C로 번역하자는 여론이 어느정도 조성되어있는 상태입니다. 파이썬 소스 코드가 311줄정도이기 때문에, 이것과 기존에 C로 구현된 _sre를 합쳐서 한개의 모듈로 만들면 속도 상 많은 이익을 얻을 수 있습니다.

• repr, sys.displayhook 국제화: 한/중/일 사람이 파이썬에 입문할 때 가장 헤메는 부분 중의 하나인 "리스트 속에 들어간 한글 제대로 안 보이는 문제"를 해결하는 원초적인 방법입니다. displayhook은 repr에 어느정도 의존하기 때문에, repr만 인코딩을 지원하도록만 수정해주면 됩니다. 그런데, 파이썬 내부의 tp_repr은 인코딩 정보를 전혀 받지 않기 때문에, 하위 호환성을 위해서는 tp_richrepr등의 이름으로 객체에 인코딩을 받아서 인코딩에 맞는 정보를 리턴해 주는 가공이 필요합니다.

• MinGW 지원: 파이썬 2.4부터는 VC 7.1을 기준으로 윈도우 빌드가 바뀝니다. 아직 MinGW에서 파이썬을 빌드하려면 아주 어려운 수동 작업을 몇몇 거쳐야하는데, 이를 깔끔하게 정리해서 메인으로 들여오면 아주 멋지겠죠~

그동안 별로 좋지도 않은 영어 실력으로 메일링 리스트에서 몇 해 활동하면서 그래도 사전도 찾고 구글도 찾고 해서 문장 만드는 것은 하고 싶은 말은 할 수 있을 정도로는 익혔는데.. (구글님의 힘 -.-v) 아 요즘따라 또 다른 문제점을 많이 만나는군요.. 으흐

아무래도 영어 메일링 리스트에서 가장 힘든 것은 상대방이 농담하는 건지, 심각하게 말하고 있는 건지 알아내는 것 같습니다. -ㅇ-; 이것.. 상대방이 농담을 한다고 치면 재미있는 말로 받아줘야할테고.. 심각한 얘기라면 또 그에 대한 사과라던지 그런게 필요할텐데.. 농담인지 진담인지 사전적인 의미만으로는 파악 못하는 문장이 나오면 당황하며.. 막강 이모티콘 :)로 넘겨보지만.. --;;

말의 분위기 같은 것은 진짜 외국에서 좀 살아야 익힐 수 있는 것 일까요? 흐흐;;

http://www.littlebsd.com/

아키하바라의 맥주집에서만 배포하는 BSD 탄생! 데모네뜨 코스튬 플레이 걸들이 서빙한다고 합니다. 와와~

어느날 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

지난 주에 이사하고서는 살림 마련하느라 여기저기 돌아다니고 방 청소하고 그러느라 영 홈피에 소홀했었군요. ^^;; 곧 사진 정리해서 웹 집들이라도;;

Miguel이 mono를 만들 적에 가장 많은 도움이 되었다고 강력히 추천한 바로 그 책! Computer Architecture: A Quantitative Approach를 드디어 한번 읽었습니다. 므흣. 이게 상당히 오랜기간 바이블급의 책이었는 듯 한 풍모가 느껴지는.. 저자 이름부터가 일단 먹어주는 군요. David Patterson - RISC의 대가이며, BSD의 할아버지! 그리고 서문은 David의 제자인 Sun의 Bill Joy가 썼습니다! (물론 지금은 Sun을 나왔지만요. ) 대단대단! 꺄아

Computer Architecture과 관련된 책은 학교에서 배울때는 늘 논리회로 어쩌고 부터 시작해서 고리타분한 70~80년대 컴퓨터 아키텍처 얘기만 줄창 나와서 어찌나 따분했는지 모릅니다. 뭔가 몸에 와닿는게 있어야 이게 내가 지금 만지는 컴퓨터가 이 책에 나오는 컴퓨터구나 생각이 들텐데.. 흐;; 그런데 이 책에서는 최근 대부분의 컴퓨터들이 부분적으로 나마 대부분 채택하고 있는 RISC를 기반으로 해서 아주 방대한 현실적인 벤치마크들과 최근 사용되는 다양한 분야의 CPU들의 특성을 고루 다루고 있을 뿐만 아니라, 고전적인 구조들도 약간씩 언급을 하고 있어서 정말 재미있네요.

그리고, 교재로서의 가장 중요한 그림과 도표! 아주 거의 2~3페이지마다 1개씩은 나올 정도로 정말 열심히 그려놔서 아주 실감이 납니다. 특히 RISC의 대가들이 쓴 것이니 만큼, 캐쉬 미스를 줄이는 전략이나 파이프라인 쪽이 이해하기 쉽게 설명이 되어있어서 그동안 뜬구름만 잡고 있었던 것을 이제 개념은 어렴풋이 알 수 있게 되었습니다. ^_^;; 물론, NUMA, RAID, 분산 공유 메모리, 클러스터 같은 실전 디자인들도 많이 다루고 있다는 것도 참 좋았습니다. 근데, 뭔가 책이 전체적으로 너무 재미있어서 교재같은 기분이 안드는 것은 약간 흠 아닌 흠 이랄까요.. (교재는 왠지 재미 없어야 한다는 통념에 사로잡혀 있다;; )

I've been in more than one heated argument about where the braces 
in C/C++ should go and I’m sure that Python programmers are 10% more
productive just because of the time they don’t spend arguing about K&R
indenting style versus others.

-- Game Scripting in Python, by Bruce Dawson

번역하자면,

그동안 나는 C나 C++에서 중괄호를 어디에 써야 하는지 과열된 싸움을 봐왔다. 
그리고, 파이썬 프로그래머들은 K&R 인덴트 스타일과 다른 스타일 사용자들과의
싸움에 허비할 필요가 없다는 점에서 적어도 10%는 더 생산적이라고 생각한다.

흐흐 그동안 K&R 인덴트가 아닌 프로젝트에 몇번 참여했던 경험으로는 충분히 10%는 넘는다고 봅니다. 어찌나 신경이 쓰이던지.. ㅠ.ㅠ

Python쪽에서 코어 개발자 메일링리스트의 이슈를 요약해서 보여주는 Python-dev Summary는 정말 메일링리스트에 직접 참여하지 않거나 잠시 아주 바빠서 메일을 못 읽었을 때에도 있었던 일을 요약해주는 정말 좋은 서비스였습니다.

이제 FreeBSD-src에서도 이런 좋은 서비스가 생겼습니다. 만세! 뭔가 공식적인 것은 아니고 어떤 사용자가 개인적으로 추진하는 것인 듯 한데, python-dev summary와 똑같이 python-docutils를 사용하여 reStructuredText형식으로 공개하는군요. 뭔가 익숙한 포맷이다 했더니.. 흐흐.. FreeBSD-current 메일링 리스트를 일일이 구독하기 힘든 분들은 꼭 요놈을 받아보면 좋을 듯 합니다. 개인적으로는 루비판인 프비에 파이썬 툴이 하나 더 사용되었다는 점에서 매우 즐겁습니다.

http://www.xl0.org/FreeBSD/

윈도우용 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에 전혀 의존하지 않는다는 점도!

우후훗. 퍼키가 고등학교때 단연 가장 좋아하던 그룹인 크랜베리스. 크랜베리는 피자 타이쿤 게임할 때나 봤었는데, 대학와서 크랜베리 쿨러라는 칵테일을 가끔.. 음~ 그래 크랜베리스가 이런 칵테일과 모종의 관계가 있군~ 하는 생각을 했었더랬습니다. 어제 심심할 때 자주하는 그랜드마트 탐사를 갔다가, 크랜베리 주스를 발견! ●ㅏ▲▲ㅏ♬

색깔이 아주 진한 붉은색인 것이 뭔가 강렬!한 체리맛 비스무리하지 않을까 하는 생각과 여러 생각이 교차하며 도저히 호기심을 이길 수 없어서 하나 덥썩 사왔습니다. 후훗. 계산대에서 바로 무슨 맛인지 마셔보고 싶은 충동이 마구 솟아올랐으나 피부 좋은 계산대 언니를 의식한 나머지 으음. 그래 집에가서 마셔보는거야 하고 부데뎅~ ∑======

아.. 집에 와서 마셔보니.. 흐흐흑. 그래 크랜베리는 이런 맛이었구나.. 이 그윽한 한약스러운 분위기의 즙.. -O-; 분명 27% 쥬스라고 했는데! 27%에서 한약 맛이 나다니! ( ノº皿º)ノ 흐흐.. 이건 굉장히 부담스러워서 쥬스로 마음 편하게 마실만하다기 보다는.. 어디 칵테일해서 먹을만한 -O-; 토마토 100% 쥬스 2배의 뻑뻑함이군요.. 으음 그래도 좀 마시다보니 괜찮은게.. 한 가끔 쥬스가 아무것도 없으면 마셔볼 만한 것 같습니다. 흐르르~흐르르~

그래요 그래도 크랜베리스 만세! ( s o )~♡

예전에 소개했던 naokis.net에서 초코렛날을 위해 신선한 "행복한 편의점 대작전"을 제안했군요! 아하. 너무 신선하다고 생각한 다른 분들도 다 같이 해보고자 하는 마음에~ 소개합니다.

행복한 편의점 대작전

14일, 편의점에 갑니다. 여성 점원이 있는 가게입니다. 예쁜이면 더 좋지요.

자, 방법은 이하와 같다.

그녀가 레지에 서 있을 때를 겨누고 초콜릿만을 구입 
                   ↓
        비닐 봉투는 필요없다고 말한다
                   ↓
          직접 건네는 초콜릿 GET
                   ↓
          행복해ヽ(*´∀｀*)ﾉ

이것은, 어느 사이트에서 본 방법입니다만...나름대로 좋다고 생각하는데, 문제점이 하나.

2월 14일에 남자가 초콜렛만 사는 것은 부끄럽다.

그렇게 생각하는 남자도 많죠.

화면 앞 당신!

궁극의 테크닉이 있습니다.

도시락도 함께 삽니다. 왜 도시락?

이유가 있는 거죠

→ 레인지로 따뜻하게 해달라고

이것.

설마, 뜨거운 도시락과 초콜릿을 같은 봉투에 넣는 비상식적인 점원은 없을 것입니다. 따로따로 봉투에 상품을 넣으려고 하는 점원에게 자연스럽게 말할 수 있는, 이 대사.

「아, 그것(초콜릿)은 봉투 됐어요(*´∀｀*) 」

라고 에콜로지스트도 아무렇지도 않게 어필.

아무튼 엄청 자연스러운 전개로

직접 건네는 초콜릿 
       ↓
행복해ヽ(*´∀｀*)ﾉ

그렇게 됩니다.

그렇지만, 극도한 긴장으로 폭주 하면 안됩니다.

「그것(초콜릿)도 따뜻하게 해 주세요」 
                ↓
「에에? 이것요? 녹어버릴 것 같애요」
                ↓
「네. 당신의 아름다운 마음으로 저도 같이 녹여 주세요」
                ↓
            점장에게 보고
                ↓
            경찰에 통보
                ↓
          （ノ∀`）아이고~

조심하세요.

원본: http://naokis.net/gul/2004.02.10/2004.02.10.htm

최근 ETech 2004에서 Nokia의 CTO가 Nokia의 차세대 핸드폰인 66 시리즈에 파이썬을 플랫폼으로 써서 핸드폰 애플리케이션들을 개발하고 있다고 합니다. 노키아가 작년에 1억대의 핸드폰을 세계적으로 판 것을 생각해 보면, 66 시리즈가 출시되면 파이썬 사용자가 대략 적어도 수천만명은 늘어나는 것인가요?

샘숭전자도 파이썬을 플랫폼으로!! 꺄꺄~~ (꿈만 꾸고 있다;; )

어제 python-dev에 Raymond가 자극적인 제목의 메일 Optimization of the Year을 올렸습니다. 내용은 예전부터 논란이 되어왔던 list.append류의 크기가 변하는 list에서 매번 realloc 을 호출해서 리스트의 성능이 크게 떨어진다는 것이었는데, 이번에 Raymond가 realloc을 안 쓰고 할당된 크기를 구조체에 저장하고 필요한 경우에만 alloc하는 걸로 바꿈으로써 realloc 이 느린 시스템에서 엄청난 성능 향상을 가져오게 되었습니다.

제 기계에서는 전체적으로 15%정도 가속이 되고, list.append는 2배로 최적화가 되었군요! 정말 좋습니다~ 그런데, 원래 Raymond의 구현에서는 list 구조체에서 내용을 저장하는 포인터인 ob_item이 외부에서 변경되는 것을 알아채기 위해서 ob_item을 따로 한벌 더 저장해 두게 되어있는데, Guido와 Tim은 앞으로 객체 추상화는 더욱 더 빡빡하게 될 것이니 외부에서 ob_item을 바꾸는 것은 도저히 용서할 수 없다는 뭐 그런 의견을 얘기하는군요. 그리고, Tim은 Raymond의 구현에서 멤버 변수가 3개나 추가돼서 리스트의 메모리상의 크기가 너무 커지는 것이 아닌가 하는 가이드까지 하며, align때문에 32비트 플랫폼에서는 공짜로 1개까지는 추가할 수 있다는 저같은 초보자는 상상도 못한 얘기를.. 정말 Tim의 무공은 바닥이 보이지 않는 바다입니다. 대단해요~ -.-b

하여간 그래서 제가 약간 고쳐서 1개만 쓰고, tracked를 제거한 패치를 올렸더니 대충 만족하는 분위기라 곧 커밋될 것 같습니다.~ 이제 2.4에서는 2배 빠른 list를! 크크크

아. 2월에는 짝수날에만 뭔가 쓰고 있습니다. 2월을 기념해서~ (;;; 사실은 의도한 것은 아닌데 어쩌다 보니;; )

요즘 거의 하루종일 Orkut 돌아다니느라 어찌나 산만한지.. 코드 좀 짜다가 10분 있다가 orkut 리프레쉬 해보고 새 친구 생기면 가서 구경하고 --;; 으흐. 아주 일을 못합니다~ 싸이 중독된 친구들을 보고 "쯧쯧~~"하던 것이 부끄럽습니다. 크크;;; -.-

그 전에도 비슷한 서비스가 많았는데, Orkut만 유독 엄청난 성공을 했고, 그 이유에 대해서 한 번 생각해 봤습니다. 의견 말씀해 주세요 이히

• IRC를 통해 전파되기에 최고의 구조다.

IRC는 인터넷 대중 커뮤니티 중에 가장 전파 속도가 빠르고 유행이 가장 퍼지는 것으로 알려져 있습니다.

혹시나 안 해 보신 분들을 위해 그 이유를 설명해 드리자면, 같은 관심사를 가진 사람들이 100명~300명씩 같은 채널에서 거의 하루종일 접속해서 얘기를 하고, 그들이 여러 중복된 채널에서 놀고 있으니 전파가 안 될 수가 없는 구조인 것이죠. +_+ 그런데, Orkut은 IRC에서 전파되기에 정말 좋은 구조로 되어있습니다. 모든 페이지의 perm url을 아주 짧게 만들어서, IRC에서 붙여넣기를 하면 다른 사람도 쉽게 같은 페이지를 볼 수 있어서, 대화 중에 등장하기가 매우 쉽다는 것입니다. 게다가, 초대로만 가입이 되고 로그인 안 하면 페이지를 볼 수가 없기 때문제 쉽게 대화에서 왕따가 되는 터라, 서로 왕따가 안 되려고 막 가입해서 결국은 IRC에서는 삽시간에 퍼져버렸고, 진짜로 Orkut을 돌아다니다 보면 초기에는 EFNet, Undernet, IRCNet 등 IRC에서 온 사람들이 주종을 이루었습니다. 그 덕에 각 IRC하는 사람들의 친구들에게 일파만파.. +_+

• 1촌과 커뮤니티를 숨길 수 없다.

사이월드는 인맥을 내세워서 처음 서비스를 시작했지만, 사실상 많은 사람들이 1촌 공개를 거부하기 때문에

인맥을 쫓아다니면서 돌 수 있는 데에는 한계가 있습니다. Orkut에서는 어떤 사람 홈페이지를 보고 있는데 5촌 관계라 하면, A > B > C > D > E 이렇게 중간에 있는 사람 이름이 모두 링크로 나와서, 아 그렇군! 하고 바로 느낄 수 있고, 아예 인맥 따라다니기 전용의 인터페이스인 View networks 모드가 있어서 진짜 재미있습니다. 커뮤니티도 각각이 동호회 성격으로 발전해버린 사이월드는 아무래도 비슷한 성격의 다음 까페류와 경쟁을 할 수 밖에 없지만, Orkut에서는 굉장히 간단하게 그냥 이름 하나 거는 수준으로 만들기도 쉽고, 수백개 가입해도 전혀 부담이 없기 때문에 커뮤니티로 관심사 네트워크를 만들 수 있다는 것도 장점으로. +_+

• 공개된 프로필이 굉장히 상세하다.

Orkut에서 가입할 때 쓰는 정보의 양은 가히 상상을 초월합니다. (거의 200항목에 달하는..) 자기 소개가 따로

필요 없을 정도로 상세한 프로필을 쓸 수 있는 가이드를 해 주기 때문에, 인맥 따라가서 프로필만 보고도 그 사람의 주요 특징 (술은 어떻게 마시고, 정치 관념은 어떻고, 가장 완벽했던 데이트는 어떤 것이고 등등..)을 파악할 수 있다는 것이 장점 +_+

• In affilation with Google

구글은 말이 필요없는 인터넷 1위 브랜드!

아아 그런데, Orkut의 약관에 따르면 Orkut에 제공한 정보는 구글이 마음대로 검색 서비스 같은 곳에 쓸 수 있다고 합니다. 그동안 안티구글의 대표주자로 구글 욕하는 글을 많이 써 온 Andrew Orlowski의 글에서 우려를 볼 수 있는데, 으음.. 뭐 정보를 가져다가 맞선 사이트라도 하려는 것일까요? -ㅇ-;

Orkut 탐험 중에 Rebecca라는 하버드에 있는 사람이 북한에 대한 블로그 NKZone을 열었다는 것을 알게 되었습니다. 흐흐. 막 시작한 것이라 아직 어떤 것이 올라올 지는 잘 모르겠지만~ 북한 탈주민들이나 실상에 대해서 자세하게 저널리즘없는 솔직한 글을 볼 수 있을 것 같아서 기대가 됩니다. +_+ 북마크 꾹~

요즘 온동네 블로그들에서 난리가 난 Orkut에 저도 가입했습니다. 므흐흐. Orkut의 FreeBSD커뮤니티는 처음 가입했던 엊그제만 해도 회원이 450명정도였는데, 이틀도 채 안돼서 680명이 넘은 걸 보면, Orkut이 엄청난 돌풍인 듯 합니다. 역시 +_+

근데 사이월드는 처음에 인맥 연결을 시도했으나, 뭔가 제대로 안 굴러가고 결국은 사진첩이 주가 되어 버리는 서비스로 변신해버렸으나.. Orkut은 아주 단순하고 구성이 온통 인맥위주가 될 수 밖에 없도록 제한이나 조정을 많이 해 놓은 것이, 뭔가 사이월드처럼은 안 될 것 같은 예감이 듭니다. 정말로 세상이 어찌나 좁은지, 웬만한 사람은 거의 6~7번 안에 갈 수 있겠더군요 흐흐~

그나저나, 오늘 python 커뮤니티에서 자기가 만든 프로젝트 소개하는 글이 올라왔는데, 괜찮은 것 두개를 발견했습니다.

• paramiko 요건 SSH2프로토콜을 pure python으로 서버와 클라이언트 모두 구현한 것!

• supybot 요건 아주 대단한 파이썬 봇이라는데.. 어디 슈가큐브보다 나은지는 좀 구경해 봐야 알 것 같군요 =3=33. 훨씬 낫다면 슈가큐브를 supybot기반으로 변신을;; 흐흐

Orkut 쓰시는 분들은 Seoul 커뮤니티에 가입을~~ 이히히

흐흐.. 대장금 31~36화 몰아보기를 하던 중.. 신비에게 빠져버렸어요. -O-; (변덕이 죽 끓듯 하다;)

아앗 그런데, 중간에 이상한 것을 몇개 발견했는데, 33화 시작부분에서 장금이가 설명하는 것에서 1,2가 동병이치이고 1,3이 이병동치라고 했는데 아무리 봐도 화면 맨 앞에 있던 병자만 다르니까, 1,2가 동병이치라면 1번이 맨 앞에있던 사람이라는 뜻인데, 그럼 1,3번이 아니라 2,3번이 이병동치가 되어야 할 것 같은데 이상하군요~ 그리고, 시험치고 나와서 장금이가 교수한테 가서 뭐라 하는 장면에서, 신교수가 지나가는 척 하고서 기둥 뒤에 숨는데, 소매자락이 펄럭거린다는.. 흐흐흐. 그 옆에 벽이라도 있는걸까요;; -O-;

작년의 히트상품~ 델몬트 Sweetened씨리즈로 요즘 Four Seasons, Guava, White Guava가 나오고 있어서, 뭔가 망고처럼 맛있을까 싶어서 흐흐흐 하나하나 다 사먹어 봤습니다. -O-;

아.. 그런데, Four Seasons랑 Guava는 영 맛이 이상한 것이 Sweetened가 맞나 모르겠군요 흐흐. 영~ 신 것이 사각사각 갈아만든 배보다 더 이상해용~ 흐흐 그런데, 화이트 구아바 오. 요것은 그런대로 괜찮군요. 사각사각 갈아만든 배랑 비스무리하면서도 약간 더 달짝지근한데, 말토덱스트린맛이 사각사각보다 좀 더하게 나서 맛이 약간 시원하게 느껴집니다. (구아바가 배인가? ;;)

늘 있던 성분 분석을!

• 화이트구아바퓨레 (20%, 이집트산), 백설탕, 액상과당, 말토덱스트린, 향료

흐흐... 사각사각 좋아하는 분은 이집트의 맛을 한번 -.-;;

요즘 포트가 바뀌는 게 무지 많습니다. 흐흐.. 좋아좋아~ 가보자구~ ;; -o-

• 드디어 -lpthread가 디폴트 쓰레드 라이브러리로: 엊그제 블로그에서 베이스가 변경되었는 것을 알려드렸는데, 이제 포트에서도 디폴트로 CURRENT에서는 -lpthread를 사용하도록 되었습니다. 그런데, 약간 몇개 뻑난다는 보고는 있기는 한데, 저는 대체로 잘 되네요. 흐뭇.

• gettext 포트가 업그레이드 되었습니다. gettext가 최근에 포트가 gettext-old로 바뀌면서 portupgrade하기가 좀 난감했는데, 이제 USE_GETTEXT가 들어오면서 어느정도 간단하게 업그레이드가 되도록 되었습니다. 그래도 잘 안 되시면 portupgrade -fo gettext-old gettext 하시면 됩니다.

• bsd.php.mk 서브시스템 추가. 드디어 PHP도 간단하게 써드파티 포트들을 추가할 수 있게 되었습니다. WITH_PHP_CLI=yes USE_PHP=yes 등의 옵션을 예쁘게 지원합니다.

• 펄 기본 버전이 5.8로 업글! 펄 사용자들의 오랜 숙원인 펄 5.8이 드디어 디폴트로 들어왔습니다. 사실 안 써서 5.6이랑 5.8이랑 뭐가 다른지는 잘 모르겠습니다. -O-

• NetBSD/OpenBSD 지원 제거. 사실 뭐 제대로 지원되지도 않았지만, 형식적으로나마 있었던 NetBSD/OpenBSD 지원이 포트에서 완전히 빠졌습니다. 이로써 프비 포트는 완전히 프비 전용으로! 얼마전에 rcNG도 NetBSD 지원이 빠졌구요.

• CHANGES 본격 가동. 이번부터 /usr/src/UPDATING 역할을 하는 /usr/ports/CHANGES가 본격적으로 가동되었습니다. marcus가 이번 변경사항에 대한 코멘트를 쓴 것이죵. 앞으로 포트의 큰 변동사항은 거기에 기록됩니다.

• USE_SIZE가 디폴트로! 이제 앞으로는 NetBSD처럼 distfiles의 파일 크기도 체크합니다. 파일 크기 체크의 영향으로 받기 전에 용량을 체크한다던지, 덜 받은 파일 마저 받기를 한다던지하는 몇가지 더 유익한 기능을 쓸 수 있게 되었습니다.

1월에 먹는 것 얘기가 하나도 없어서 결산으로 흐흐흐;;

대구/경북에만 있는 피자 까펠로의 "고추장불고기 피자"입니다. 아 그 피자헛의 스테이크스러운 이상한 맛의 불고기피자보다 훨씬 낫네용. 고추장불고기의 새콤달콤매콤한 맛이 아주 멋지게 어울립니다. 토마토 계열 토핑이 빠졌기 때문에 피자 싫어하는 분들도 쉽게~ 와와. 대구에 가면 꼭 고추장불고기 피자를 드셔 보세용. _-_ 기로스의 Fresh Greek Salads

이대 바로 앞 럭키아파트 올라가는 길에 있는 그리스 음식점 기로스(Gyros)의 Fresh Greek Salads입니당. 흐흐 그리스 음식이면 뭔가 웅장하고 그런 신비로운 맛이 날 줄 알았는데, 크게 독특하진 않군요.. 뭔가 너무 안 독특해서 가짜 그리스 음식점이 아닐까 하는 의심이 -.-;; 떡 볶은 것과 치킨이 위에 올라가 있는데, 떡 볶은 것이 아주 샐러드에 잘 어울려서 저도 집에서 함 해봐야 겠다는.. 가격도 싸고 양도 적당하고 맛있습니당~ 그리고 주인 아저씨는 친절하지만, 아주 불친절한 주인 아줌마가 그 사이를 메우고도 남으니 마음 단단히 먹고.. (..) 그 외에 수.. 쿠... (이름이 희한해서 -.-) 뭔가 3~4개정도 메뉴가 더 있었는데, 3인분 세트가 거의 안에 들어있는 메뉴가 8인분 어치는 되는 것이.. 역시 그리스 사람들 비만인 비결이 -.-bb 싸고 깔끔해서 가볼만 합니다. 추천~

포트에서 아주 불편했던 것 중 하나인, 업그레이드 때 보존이 제대로 되지 않는 WITH/WITHOUT 옵션들이 있었습니다. 아무대로 make 옵션으로만 임시로 쓰다보니.. 하여간, 며칠 전부터 이제 포트에서도 /var/db/ports에 포트 옵션을 기록하게 되었습니다. 그래서 포트를 깔 때 주었던 WITH, WITHOUT 옵션을 /var/db/ports/options/xxx-1.2_3 이런 파일에 기록해 둔다는 형태인데, 옵션들을 일일이 포트자체에 변수로 나열해 줘야하기 때문에, 아직 많은 포트에서 지원되지는 않습니다. 그리고, 이 옵션 체크가 bsd.port.pre.mk를 인클루드한 다음에 이뤄져야하는데, 정작 USE_PYTHON=yes나 USE_GNOME= gtk20같은 옵션들을 위해 WITH_PYTHON=yes나 WITH_GNOME=yes같은 옵션을 쓰는 경우에는 bsd.port.pre.mk 앞에 또 써 줘야하기 때문에, 이게 순서가 안 맞아서 이런 경우가 지원이 불가능합니다. 게다가, 어찌나 지저분한지.. 흐흐. 과연 고쳐질 수 있을지 모르겠네요.. 이러다가 include가 3개로 늘어나는게 아닌지 --; 기왕 하는김에 NetBSD처럼 빌드링크를 직접 인클루드하게 하는 것도 좋을 것 같고..

요즘 추가되고 있는 포트 옵션들을 보면, 필요해서 추가되는 것이기는 하지만, 너무 지저분해지는 게 아닌가 싶은게 많습니다. 아예 DarwinPorts처럼 뭔가 애플리케이션 차원의 깔끔한 포트를 만들어 봤으면 하는 기분에 DarwinPorts를 프비에서 또 한번 돌려 봅니다. -.-;