James Watson의 “권리”에 대한..

신성함과 같은 용어는 나에게 동물의 권리를 연상시킨다. 누가 개에게 권리를 주었는가? 권리라는 이 단어는 매우 위험하다. 여성의 권리, 아동의 권리가 등장했으며, 이제 권리의 목록은, 끝없이 이어지고 있다. 그렇다면 도롱뇽과 개구리의 권리도 있지 않겠는가. 터무니 없는 일이다. 나는 권리나 존엄과 같은 말은 사용하고 싶지 않다. 인간은 욕구를 가지며, 사회적 종으로서 그러한 욕구(음식이나 교육, 건강 등)에 반응할 따름이다. 사이비 신비주의적인 방식으로 의미를 부풀리려는 것은 스티븐 스필버그와 같은 사람들에게 적당하다. 내 말은 허황된 소리에 지나지 않는다는 뜻이다.

— 제임스 왓슨, 2000년 회의 기록문 Stock and Campbell p.85

원래 Francis Fukuyama의 책에 인용된 내용이지만, 그의 책에서는 이 말을 인용한 뒤에 부분적으로 반박하는 말이 따르기 때문에, 재인용이라고 저것만 똑 따기에는 좀 억울한 면이 있습니다. :) 인권에 대해 많은 것을 생각해주게 하는군요~ (James Watson의 말에 100%동의한다고 하면 뭔가 사회적 인간이기를 적당량 포기한다는 말을 하는 것 같아서, 적당히 얼버무리고 도망.. =3 =33)

Python.NET

[WWW]ActiveState에서 만든 구리구리한 Python.NET 말고 Zope에서 만들고 있던 PythonNet이 Preview 2가 발표가 됐군요~. 아직까지는 MS.NET CLR하고만 제대로 돌아가지만, Mono로도 곧 되지 않을까 싶습니다. 흐흐

타볼을 풀어보면 빌드하기는 좀 아리송 하고 (뭔가 싸인을 하려면 인증서가 있어야 한다는데, 배포는 같이 안 하는군요) 바이너리가 들어있어서 그걸로 실행해 보면 됩니다.

짠 실행해 보면

흐흐 Jython 처럼 뭐 플랫폼이 바뀌는 것은 아니고, 그냥 일반 CPython과 CLR의 중간 연결고리만 만들어 놓은 녀석이라, 플랫폼은 그냥 네이티브로 나옵니다. 그리고, 파이썬 바이트 코드들은 .NET 어셈블리로 바뀌어서 실행되는 게 아니라, 전부 CPython VM이 실행하고 중간 데이터 교환만 PythonNet이 담당해서 CLR에게 전해지게 됩니다.

WinForm도 벌써부터 잘 되네요 흐흐..

0308-pythonnet.png

모노 CP949 코덱 완성

오픈소스 닷넷 프레임웍인 [WWW]Mono를 위한 CP949 코덱을 완성했습니다. 크크크~~ (사실 뭐 별 건 아니지만;;;)

그동안 I18N.CJK.dll이라고 이름 붙은 것이 K를 지원 안해서 아주 좀 보기가 그랬지만 그래도 이제는 진짜 CJK~ 근데, 막상 버그질라에 보내려고 접속해 보니 버그질라가 죽었는지 접속이 안 되네요 –;

코덱이 없으면 이렇게 나오던 것이~ (윈도우에서는 UTF-8로 나오고, 리눅스와 FreeBSD에서는 요상 야릇해서 도저히 해독할 수 없는 것으로 나옵니다 ;;)

0308-mono-wocodec.jpg

코덱이 있으면 이렇게 나옵니다.

0308-mono-withcodec.jpg

최근 CVS 버젼에 대해서 작업했는데, 바이너리 파일이 하나 끼여있기 때문에 패치는 못 만들고 그냥 풀어서 덮어씌우는 타볼을 만들었습니다. http://openlook.org/distfiles/mono-cp949.tar.gz 에서 받을 수 있습니다.

보통 디코더로 byte[]를 char[]로 변환할 때 이런 방법으로 쓸 수 있습니다. (어렵게 알아낸 것 –;;;;;;; 코덱을 만들긴 했는데 시험을 못해보니 어찌나 답답하던지요 -ㅁ-;)

ko_KR.CP949 등록!

“쀍”과 “햏”같은 글자를 쓰기 위한, 필요악 인코딩인 CP949(CodePage 949)를 기반으로 한 한국어 인코딩이 FreeBSD에 추가되었습니다. (이 블로그는 UTF-8을 쓰기 때문에 그렇게 나쁜 편은 아닙니다 히히~)

그냥 터미날같은 데서 적당한 프로그램들을 쓰면, 이제 확장완성형 글자들도 특별히 깨져서 나오지는 않을 것입니다. 완전하지 못한 점이 하나 있다면, 아직 FreeBSD가 multibyte collation을 지원하지 않아서 collation에 대한 고려가 전혀 되어있지 않다보니, 한글 정렬이 제대로 안 될 것입니다.

그리고, screen에서는 원래 한국어를 쓸 수 있는 인코딩이 euc-kr과 UTF-8밖에 없어서, CP949패치를 따로 해서 넣으려고 하고 있습니다.

[WWW]CVSWEB

「사기열전」중에서..

하규의 책공은 이렇게 말했다. 처음 내가 정위가 되었을 때는 빈객이 문 앞에 가득 찼지만, 파면되자 문밖에 참새 잡는 그물을 쳐도 될 정도였다. 내가 다시 정위가 되자 빈객들은 예전처럼 모여들려고 했다. 그래서 나는 문에 이렇게 크게 써서 붙였다.

한 번 죽고 한 번 사는데 사귀는 정을 알고, 한 번 가난하고 한 번 부유함으로써 사귀는 모습을 알며, 한 번 귀했다가 한 번 천해짐으로써 사귀는 참된 정을 알게 된다.

“사기열전”中에서

(박카스를 좋아하시는 [WWW]ddt님의 홈페이지에서 재인용)

ktrace(1)를 이용한 자동 plist 생성

포트를 만들거나 업글할 때 가장 귀찮은 과정 중의 하나인 plist를 자동으로 만드는 방법은 [WWW]mtree기반으로 된 것이 있었지만, 뭔가 다른 프리픽스로 한 번 깔아보는 게 대략 귀찮은 관계로.. [FreeBSDMan]ktrace 를 이용한 방법을 한 번 생각해 봤습니다. 흐흐흐.. open 시스템 콜을 모두 추적해서 O_WRONLY나 O_CREAT로 열린 녀석들 목록을 자동으로 plist로 만들어주는 것인데, 대충 만들어 본 소스는..

흐흐.. 그런데, 대충 만들고 나서 보니, 속도가 너무 느리고 (좀만 대형 포트로 가면 엄청난 양의 kdump가 나와버려서 그것 파싱하는데 십분이 넘게 걸립니다 –;) mtree기반의 녀석에게 특별한 장점이 없다는 결론이.. 흐흐흐… (그리고, 위 구현에서는 디렉토리를 인스톨 도중에 mv 해 버린다던지 하는 것에 대해서 무방비 –;)

그래서, 이 녀석을 좀 변모시켜서 plistlint 정도의 이름으로 인스톨하면서 plist에 없는 프로그램 건드리지는 않나, 빼먹은 파일 없나, /tmp에 이상한 파일 남기지 않나 등등을 검사하는 걸로 만들어 볼 까 합니당. 크크

파이썬 2.3의 공유 라이브러리 지원

이미 해본 분들은 아시다시피 ~.~, 파이썬 2.3에서는 –enable-shared를 주면 공유 라이브러리로 사용이 가능하도록 돼서, libpython2.3.so가 1메가짜리가 나오고 python은 3천 바이트짜리가 나옵니다.

그래서, 이야 멋지다 하고 메모리 절약에 도움이 되지 않을까 하는 생각에, FreeBSD포트 [FreshPorts]lang/python 에는 덥썩 shared를 디폴트로 해 버렸는데, 다행히도 python-dev 메일링에 누가 “왜 –enable-shared가 디폴트가 아닌가요”하는 질문에 Martin v. Löwis가 좋은 대답을 해 주어서, 덕분에 잘못 알고 있었던 것을 바로 잡게 되었습니다. 으흐흐 (다들 알던 것인가;;)

웬지 공유 안 할 것 같아 보였던, static 바이너리도 inode가 같은 경우에는, text 이미지를 메모리에서 모두 공유한다는군요 (두둥!) ~.~;;

Löwis의 가르침(!)을 요약하면..

  • 파이썬 바이너리가 1개만 있으면, 걔네들은 모두 공유라이브러리 만큼 전부 메모리나 디스크 공간을 공유한다. 그런데, 거의 대부분의 파이썬 애플리케이션들이 파이썬 바이너리를 따로 쓰는 게 아니기 때문에, 대부분의 파이썬 애플리케이션들은 실행 파일 이미지를 메모리에서 공유한다고 볼 수 있다. 특별한 예외라면 [WWW]mod_python이 있는데, mod_python은 아파치 바이너리를 통해서 공유돼서, 다른 파이썬 바이너리와는 공유하지 않지만, 아파치 바이너리들 끼리 공유해서 같은 효과를 얻는다.

  • 공유 라이브러리를 유지하는 것은 상당한 관리상 문제점이 따른다. 어떤 경우에는 인스톨이 제대로 안 될 수도 있고, 공유라이브러리 링커에 따라 못 찾게 될 수도 있다.

  • 공유 라이브러리를 사용하면, 시작하는 시간이 길어진다. 또한, [WWW]ld.so에 디렉토리가 몇 개 더 추가되어야 하고, 빌트인 모듈로 컴파일되지 않은 파이썬 모듈까지 모두 공유라이브러리 패스에 들어가야 한다. (퍼키 주: 이 부분은 적어도 FreeBSD에서는 사실이 아닙니다. FreeBSD에서는 그냥 [WWW]dlopen(3)으로 절대경로찾도록 되기 때문에, 정적 컴파일한 것이나 같습니다.)

  • 공유 라이브러리를 사용하면, 실행 시 효율성이 떨어진다. PIC (Position-Independent-Code)는 일반적으로 non-PIC 바이너리보다 최적화에서 불리하다. ([WWW]블루님 주: 현실적으로는 거의 차이가 없다고 합니다. 😉

  • 공유 라이브러리를 들고 있으면, 관리 비용이 더 많이 든다. 컴파일러, 링커, 다이내믹 링커 등등 거의 모든 개발 툴에서 기존에 없었던 문제가 발생될 수 있고, 이에 대해서 일일이 고려해야한다.

  • 흐흐흐. 그래서, FreeBSD의 [FreshPorts]lang/python 포트도 별도의 공유 라이브러리 포트를 분리해 내고, 정적 컴파일로 다시 돌리려고 합니다. 만세 \(-.-)/

    (Martin v. Löwis의 원문은 [WWW]http://mail.python.org/pipermail/python-dev/2003-August/037472.html)

    4-STABLE의 PAE 지원

    FreeBSD의 물리적 주소 범위를 4GB이상으로 넓히는 Jake Burkholder의 PAE 옵션이 Luoqi Chen의 포팅 작업으로 4.x에 성공적으로 포팅돼서 그동안 많은 테스트가 있었는데, 이제 이번 주 금요일에 PAE가 4에 임포트가 된다고 합니다. PAE를 사용하는 드라이버같은 것들이 따로 아직 많은 편은 아니기 때문에 직접적인 영향은 없으리라 생각되지만, 그래도 안정적인 시스템 운용이 필요한 분들은 다음 주까지는 좀 미루시는 것이 좋겠군요. :)

    PAE가 들어오면 이제 FreeBSD 4에서도 4GB이상의 메모리를 쓸 수 있고, 2테라 이상의 단일 스토리지를 쓸 수 있게 됩니다. :) 그리고, 이것을 포함한 다음 릴리즈는 9월 예정인 FreeBSD 4.9! ~.~

    FreeBSD의 python2.3에서 py-xml문제

    python2.3의 _xmlplus 최소 버전이 0.8.2로 되어있어서, FreeBSD 포트 [FreshPorts]textproc/py-xml 으로는 python2.3에서 쓸 수 없었던 문제가 있었습니다. (사실은 그 문제 때문에, openlook도 잠시 cgitb 판이 됐었;; ~.~) 메인테이너인 wjv가 지금 직장을 옮기느라 바쁜 상태라서, 그냥 방금 0.8.3으로 업그레이드해 버렸습니다. 혹시 파이썬 2.3에서 py-xml이나 pyblosxom쓰시는 분은 이제 업글하시면 제대로 될 겁니다. ;)