Month: September 2004

오늘 소스포지에서 메일이 하나 왔는데 마치 개인메일처럼 와서 자세히 읽어 봤습니다. 내용을 보니 소스포지 관리자가 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를 사용하기 시작했다. 가장 쉽게 생각할 수 있는 공격은 무한 루프다. 모델을 뷰에서 완전히 독립하고, 페이지 제어를 금지함으로써 보안성을 얻을 수 있다.

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

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

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

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