computer

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

지난 주에는 퇴근길에 읽을 만한 문서를 보다가 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 작업하느라 좀 바뻐서 금방은 패치를 못 내놓을 것 같고 주말에는 돼야 겠네요~ 으흐흐; 우선 급하시면 오리지날 판을 쓰세요~ ;;