CJKCodecs 1.0.3 릴리즈

한/중/일 파이썬 유니코드 코덱인 CJKCodecs 1.0.3이 릴리즈되었습니다. 1월 3일 맞추느라 좀 서둘러서 -O-;; (사소한 것에 집착;;)

변경사항은 대부분 일본어 지원에 관한 것이라 한국어 관련 인코딩에서는 iso-2022-kr 코덱이 MSB세팅된 글자에 대해 에러내게 바뀌었다는 것 밖에 없습니다.

다운로드는 http://cjkpython.i18n.org/#CJKCodecs 입니다.

(_ _);

그래 우리는 도구를 쓰는 인간인게야!

어릴 때부터 이빨은 위아래로 슥슥 닦는 거라고 지겹게 배워왔던 유치원, 초등학교 시절.. 언제나 왜 그렇게 닦아야 하는 지에 대한 불만이 무척 많았습니다. 왜 왼쪽 오른쪽으로 닦으면 신나고 재미난데 지겹고 짜증나게 위아래로 닦아야만 하는 것인가! 아 그런데, 정말 오래산 보람이 (-.-) 있군요. 드디어 왼쪽 오른쪽으로 닦아도 되는 칫솔을 발견한 것입니다! 꺄아~

0401-teethbrush.jpg

질레트라는 면도날로 유명한 회사에서 만든 것을 수입한 Oral B 칫솔인데, 아예 기본으로 중간 솔들이 반반씩 반대로 누워있어서, 그냥 왼쪽 오른쪽으로만 닦아도 위아래로 닦는 효과가 나는 데다가 가운데 솔이 프라그를 녹여내는 역할 까지한다는 것입니다! 우와와~~ 역시 사람은 도구를 쓰는 거야 ㅡ.ㅜ 그래! 호모 에렉투스는 이빨을 굳이 위아래로 닦을 필요는 없는거야.. 감동의 물결이.. 흑흑~~

역시 2004년에도 불편을 극복하는 한해를 살아야겠습니다. 이것을 올해의 초칙으로 한다! (패러디;)

참고: 이 글에서는 대충 써버렸지만, 호모 에렉투스는 현생 인류인 호모 사피엔스의 조상이 아니라는 분석이 학계에서는 정설입니다.

FreeBSD 포트 10000개 돌파!

[WWW]FreshPorts 통계에 따르면 어제나 엊그제 포트가 10000개가 넘었다고 합니다. (정확히는 어느 포트가 10000번째인지 분석은 아직 나와있지 않고 몇 명이 분석 중인 듯 합니다. :) )

현재 바이너리 패키지 수로는 [WWW]Debian Linux가 가장 많지만, 데비안은 같은 프로그램이 여러 패키지로 나뉘어 있는 경우가 FreeBSD에 비해 아주 많고, 같은 프로그램의 여러 브랜치가 동시에 패키징 되어있는 빈도도 훨씬 높은 편이라, 사실상 10000개의 패키지를 제공하기로는 FreeBSD가 최초가 아닐까 합니다! (억지 1g ;;)

7000개부터 10000개가 될 때까지 많은 노력을 해 왔던 사람들 3명이게 Jordan K. Hubbard (jkh)가 전에 상을 주기로 했던 적이 있었는데, 과연 실제로 할 수 있을 지 모르겠네요.. (상황이 상황이라.. 😉 아무래도 끊임없이 엄청난 양의 빌드로그를 (직접 보는지는 몰라도) 메일로 보내서 메인테이너들을 괴롭혀서 포트 품질 유지에 큰 힘을 쓴 Kris Kennaway (kris), 불모의 포트 땅에 portupgrade라는 천혜의 도구를 만들어 준 Akinori MUSHA (knu), GTK/GNOME 계열의 포트 대부분을 거의 혼자 관리해 오면서 높은 품질의 좋은 GUI 포트들을 많이 제공해 준 Joe Marcus Clarke (marcus)가 되지 않을까.. 에 올인 =3 =33

(새해에는 모두 여자친구 생기시길~~ ;;; — 이미 있는 분은 말구요 _-_ )

CJKCodecs 1.0.3 RC

http://people.freebsd.org/~perky/cjkcodecs-1.0.3c1.tar.bz2

CJKCodecs 1.0.3 RC를 공개했습니다. 일본인들에게 리뷰를 요청했는데, 결과를 받아본 뒤에 1~2일 내에 정식 릴리즈를 할 예정입니다.

수정된 사항은:

  • ISO-2022-JP 코덱들에서 JIS X 0208의 0x21/0x40이 원래 매핑이 되어있지 않던 것이, U+FF3C에 매핑되도록 바뀌었습니다.

  • ISO-2022 코덱들이 JIS X 0208:1978 시퀀스를 인식하지 못하던 문제를 고쳤습니다.

  • ISO-2022-JP{,-1,-3} 코덱은 이제 SI, SO를 사용하면 디코드 에러를 냅니다. (JapaneseCodecs 와의 호환성)

  • EUC-JP, SHIFT-JIS 코덱에서 사용자 정의 구역(PUA) 지원을 제거했습니다. 실제로 일본인들은 이 구역을 안 쓴지 오래됐다는군요.

  • ISO-2022 코덱들의 디코더에서 MSB가 세팅된 글자가 넘어오면 디코드 에러를 냅니다.

  • ISO-2022-JP 코덱들이 이제 JIS X 0208:1997 시퀀스 (ESC & @ ESC $ B)를 지원합니다. RFC에 등록된 것은 아니지만, 실제로는 쓰인다기에..

  • 진짜 ISO-2022-JP-EXT 코덱이 들어갔습니다. (ISO-2022-JP-1 + JIS X 0201 반각 카타카나 지원)

리눅스에서 FreeBSD로 변신하기 – Depenguinator

[FreshPorts]security/freebsd-update 로 유명한 Colin Percival이 또 한번 사고를 쳤군요 :)

NetBSD쪽에서도 뭔가 방법이 나온 듯한데, 하여간 잘 돌아가는 [WWW]리눅스에서 FreeBSD를 까는 방법을 공개했습니다. :) 콘솔에 직접 접근할 수 없는 원격 머신에서도 깔 수 있다는 것이 장점인데, 이걸로 스스슥하다가 실패하면. (-ㅇ-;) 구체적으로 쓰인 방법은 [FreeBSDMan]dd 로 임시로 인스톨러를 원격에서 접근할 수 있도록 띄워주는 부팅 디스크를 하드디스크 앞쪽에 넣어서 리부팅하는 방법으로 보이는데, 저는 원격에 있는 펭귄이 없어서 depenguinate를 해보지는 못하겠네요 ;;

이제 리눅스 사용자들이 undaemonizer를 만들 차례~ 잇힝~ ;;

screen에서 화면 스크롤 위로 올리기

으흐흐. 3년동안 모르고 있었던 이 좋은 기능을;; -ㅇ- screen도 pgup이 가능하네요! (나만 모르고 있었나;;)

바로.. 그것은.. Ctrl-A [ 누르면 들어가는 카피모드에서 pgup/pgdn이 된다는 것~! 물론 ctrl-f ctrl-b도 되구요.

.. 영 쓸모 없는 줄 알고 있었던 copymode인데 스크롤이 되는군요 흐흐; 스크롤 저장 줄 수는 .screenrc에서 defscrollback 1000 을 써주면 1000줄씩 저장된답니다. 와와~~

XFce에서 “항상 맨 위에”쓰기

동영상 볼 때마다 정말 절실했던 기능 “항상 맨 위에”가 드디어 XFwm에도 들어왔네요. 흑흑 그동안 동영상 보려면 구석탱이에 띄워놓고 다른 프로그램 안 겹치게 조절하느라 힘들었는데.. 이제 XFce유저들에게도 봄이 온 것입니다~ 으훗.;;

[WWW]Master^Shadow라는 사람이 패치한 것인데, 바로 CVS에 적용이 된 듯 합니다. 패치를 받아서 설치해 보니 무척 잘 되는군요. ^_^

요즘 열심히 보고 있는 Walking with Dinosaurs를 “항상 맨 위에”로 띄운 것

0312-xfcealwaysontop.jpg

KLDP.net주최 HHK컵 2위;;

[WWW]KLDP.net주최 HHK컵 투표에서 2위를 했습니다. 꺄~~♡ peer간 투표에 가중치가 붙어서 생기는거라 아주 짜고치는 고스톱으로 –;; (여러모로 봐도 krisna님이 1위하셔야 하는뎅.. 흐흐 =3)

상품으로 Happy Hacking Keyboard를 받았습니다. ^^; 흑흑 그런데.. 정말 슬픈 일 하나는… KLDP.net 투표 상품이 발표되기 전날 제가 HHK를 충동구매 했다는.. 우에엥… 그래서 결국은 HHK가 2개가 생겨버렸습니다. -.- 충동구매한 것은 검은색이고 상품으로 받는 것은 흰색이라 그나마 색깔이 달라 다행이지만;;

충동구매한 불운의 HHK 검은색 ㅡ.ㅜ

0312-hhk.jpg

그런데, 놀란 것은.. 아론을 쓰다가 바로 HHK로 바꿔서 그런지 생각보다 HHK Lite 키감이 너무 안 좋았다는 것인데, scari님에 따르면 M모사 부사장님은 HHK Lite의 키감을 “쫄깃쫄깃하다”라고 표현하셨다는데, 제 표현으로는 “뚝컥뚝컥하다(말을 새로 만듦;;)”라고 말하고 싶군요; 영문배열이라 그런지 처음 들어가는 힘도 전혀 32g던가 스펙보다 훨씬 무거운 것 같고, 눌린 후에 들어가는 힘도 상당히 많이 든다는 점에서.. 써본 키보드들의 키감만 갖고 평가하기는 아론 – LGK3000 – MS Natural – HHK Lite – 삼성 정도의 순서로 하고 싶군요~ 크;

그런데, 키감외 다른 측면에서는 아주 좋았습니다. 딥스위치 3,4번을 켜서 Alt와 다이아몬드를 바꾸고, BS와 Delete를 바꾼 뒤에는 별로 자리가 헷갈리지도 않았고, 왼쪽 Ctrl을 손바닥으로 누르는 것에 그동안 집착을 해 왔었는데 생각보다 HHK식으로 새끼손가락으로 누르는 것도 괜찮더군요; 다만, 리버스 솔리더스랑 딜리트의 위치가 MS나 Apple키보드와 반대라는게 좀 불편하네요. 딜리트는 위에 있는 게 더 편한 것 같은데.. USB 포트도 2개짜리 허브가 달려있어서 (내부적으로는 3개) 아주 좋았습니다. :)

회사 데스크탑 (HHK Lite2와 MS Wheel Optical)

0312-hhk0.jpg

결론은 아론에서 HHK를 만들면 정말 좋겠다는 생각이.. (와와~~)

ANSI/ISO/IEC C 타입의 실체

지난 [WWW]8비트가 아닌 char 사건 때 C 타입이 그동안 알아왔던 것과는 다르구나 하는 느낌이 있었는데.. 새로 다른 쓰레드에서 IPv4 어드레스같은 용도를 위해 고정된 크기의 표준 타입이 있으면 좋겠다는 제안에 답변을 받으면서 C 타입을 새로 공부해야겠다는 생각이 들었습니다. 으흐흐;;

[NoSmoke]원전의중요성에서도 누차 강조됐듯, 백날 C 책을 읽어봐야.. ANSI/ISO C 문서를 안 읽고서는 C를 안다고 말하기가 부끄러운 것인 것을 이제서야 깨닫게 되었다는.. ㅡ.ㅜ (진짜 원전이야 K&R white book이기는 하지만, 아직까지 K&R 문법만 지원하는 컴파일러는 대형 메인프레임/유닉스 서버에서나 볼 수 있는 것이니까;;)

하여간, 찾아서 본 ISO C 문서에서의 바이트 정의는 이런 것이었습니다.

byte addressable unit of data storage large enough to hold any member of the basic character set of the execution environment (실행 환경의 기본 문자 세트 전체를 담을 수 있을 만한 충분한 크기를 가진 주소 지정이 가능한 데이터 저장 공간의 크기)

  • NOTE 1 It is possible to express the address of each individual byte of an object uniquely. (각각의 바이트는 주소로 표현될 수 있다.)

  • NOTE 2 A byte is composed of a contiguous sequence of bits, the number of which is implementation defined. The least significant bit is called the low-order bit; the most significant bit is called the high-order bit. (바이트는 연속된 비트들로 조합되어있는데 그 수는 구현에 따라 정의된다. 가장 낮은 비트를 low-order bit라고 부르고 가장 높은 비트를 high-order bit라고 부른다)

즉, 그동안 수많은 입문서, 교과서, C 관련 서적, 상식서적, 수험서적에서 나왔던 “바이트는 8비트를 묶은 것을 1바이트로 부르는 단위다.” 이런 것은 쌩판 거짓말이었던 것입니다. ;; 그리고, int, short, long등의 정의도 “16비트 컴퓨터에서는 16비트임” 뭐 이런 것과는 차원이 다른, 그냥 char 크기의 n배이다. 뭐 이런 정의 밖에 없다는 것을 발견할 수 있습니다. (크기는 구현하는 사람 맘대로..) 그런데, 진짜 크기를 구체적으로 지정할 수 있으면 얼마나 좋을까하는 생각에, 좀 더 찾아보니 POSIX 확장 헤더인 줄로만 알고 있었던 stdint.h와 inttypes.h가 ANSI/ISO/IEC C99에도 있는 것을 발견! (stdint.h는 7.18, inttypes.h는 7.8에) stdint.h와 inttypes.h에 있는 타입들은 extended integer types라고 부른다는데, stdint.h에는 int16_t uint32_t 이런 타입들이 정의되어있고, inttypes.h에는 [FreeBSDMan]fprintf 류 함수를 위한 PRI 시리즈와 [FreeBSDMan]fscanf 류 함수들을 위한 SCN 시리즈 매크로가 있는데, PRIdLEAST32 (fprintf의 %d에서 사용 가능한 가장 작은 32비트 타입), SCNuFAST16 (fscanf의 %u에서 사용 가능한 가장 빠른 16비트 타입) 이런식이네요..

ANSI/ISO/IEC C 문서는 ANSI 홈페이지에서 30달러에 파는데, ISO 워크그룹 홈페이지에서 [WWW]마지막 드래프트를 공짜로 받을 수도 있습니다. 흐흐;;