Inquirer에서 이 기쁜 소식을 접하고, http://www.mozilla.org/에 접속했으나, 아무런 반응이 없길래, 사이트 폭주라고 추측했는데, 2시간 쯤 후에 올라온 slashdot article의 comment들을 봐도 역시 그런 것 같다.
웹사이트에는 들어갈 수 없지만, ftp에서 받을 수 있다. Firefox 1.0 win32 버전을 받으려면, 여기를 클릭.
가끔씩 Firefox가 죽는 현상이 일어나서 좀 괴로왔는데, 1.0 버전에서는 말끔하게 해결되길…
Update : 아직은 Google Bar를 비롯한 extention들이 update 안된 상태이므로, 조금은 인내심을 가지고 기다리는 것도 좋을 듯 하다.
살인의 ‘추억’이라기보다는 살인의 ‘꿈’이 적절할 것 같다. 뭔가를 잘못 먹어선지, 아님 단순한 독감인지 몰라도, 어저께부터 두통이랑 열이 나기 시작했다. 결국 어젯밤엔 잠을 잘 못자고 꿈까지 꾸었는데, 이상한 꿈이었다. (그러고보면 요즘에 꾸는 꿈이 전부 이상하다)
비가 추적추적 내리는 어두컴컴한 밤에, 나는 혼자서 운전을 하고 있었다. (면허도 없는…사람이…?) 그런데, 갑자기 앞에 사람이 나타나서, 피하지못하고 치고 만다. 그 사람은 즉사한 모양이어서, 난 그 시체를 집으로 가져와서 식탁에 내려놓는다. 친구인지 배우자인지 모를 다른 사람과 나는 그 시체를 며칠 동안 식탁에 방치한 채로, 어떻게 처리할 지 논의한다. (토막내서 운반이라든가…)
꿈을 꾸고나서 메모를 해놓은 건 아니라서, 여기까지 이상은 잘 기억이 나질 않는다. 조만간 무슨 일을 저리르지 않을까? 주변분들은 주의하시라. 살인의 예감.
아파서 뒹굴거리면서, 케이블에서 본 영화. 드류 베리모어가 신데렐라로 나온다. 신데렐라를 각색한 영화. 영화에서는 신데렐라의 지적인 면(?)에 왕자가 반하게 된다는 내용인데, 아마도 신데렐라 스토리에 대한 비판적 시각을 의식한 것 같다. 할리우드에서 자주 보이는 청춘 러브 스토리에 준하는 영화.
병역 특례 복무 기간이 2004년 10월 29일부로 끝나서, 그동안 생사고락(?)을 함께 한 팀원들과 식사를 했다. (무..물론 내가 쐈다.)
새로 산 IXUS 50으로 찍은 사진인데, 실내에다가 워낙 어두워서 그다지 quality가 좋지 못하다.
/celebration.jpg)
다음은 Picasa로 export한 앨범 페이지. comment를 달 수 없는 것이 단점이라면 단점인데, XML로도 export가 가능하니, 툴과 연동되는 그럭저럭 쓸만한 앨범을 만들 수 있지 않을까 생각이 든다.
http://www.lastmind.net/data/Pictures/Celebration%20party%20(platform%20development%20team)/
From http://article.gmane.org/gmane.comp.lib.boost.devel/112562/
곧 release될 boost 1.32의 변경사항들이다.
매우 유용할만한 Multi-index containers나 Program Options, 새로 제안된 iterator 개념을 구현한 Range Library, C++에 없어서 불편했던 string utility – String algorithm, stream과 연동해서 여러 sink로의 serialization방법과 filtering 방법을 제공하는 Serialization framework가 새로 추가되었다.
http://www.meta-comm.com/engineering/boost/1_32_0_draft/
http://www.meta-comm.com
http://www.meta-comm.com
http://www.meta-comm.com
adjacency_list and adjacency_matrix class templates, greatly simplifying the introduction of internal vertex and edge properties.For complete list of changes see Test Library release notes.
IXUS V를 소장하고 있었으나, 가지고 다니기가 불편해서, 좀 더 작은 모델을 구입했다. FX7이나 IXUS i/i5등이 마지막 순간까지 경합했으나, zoom 기능을 가지고 i/i5랑 크기가 거의 비슷한 모델인 IXY 50을 선택했다. 솔직히 300D 같은 SLR 기종을 사고 싶은 마음도 있었지만, 현재의 내 생활 패턴을 보건데, 제대로 활용할 가능성이 없고, 혹여라도 차후에 여행을 많이 다니게 되거나 하게 된다면, 그 때에 그러한 모델을 사더라도 별 문제가 없다고 판단했다.
IXUS V는 A/S를 받은 후에 (그래도 LG 정품) 동생에게 주거나, 아니면 팔아버릴 생각(과연 팔릴 지가…)이다. (혹시 마음이 있는 사람이라면 contact 바랍니다.)
다음은 IXY 50의 사용기. http://tinyurl.com/6gsf9
Problem
Linux 시스템의 (swap을 포함한) 메모리가 모두 소진된 상태에서 중요한 프로세스(e.g. server app)가 OOM killer에게 죽는 현상이 발생할 수 있습니다. OOM killer가 무엇이고, 중요한 프로세스를 살아남게 하려면, 어떻게 해야할까요?
OOM killer is…
http://www.win.tue.nl/~aeb/linux/lk/lk-9.html#ss9.6
OOM(Out-Of-Memory) killer는
– a) 특정 (메모리가 부족한) 상황에서 동작해서,
– b) 특정 알고리즘에 의해 프로세스를 선택,
– 해당 프로세스를 kill 해서 메모리를 확보합니다.
OOM killer & Overcommit
위의 page에서는 OOM의 존재 자체가 일종의 버그라고 말합니다.
linux는 overcommit, 즉, 실제로 필요로 하는 메모리보다 더 많은 메모리를 (가상적으로) 할당하는 정책을 사용하기 때문에,
OOM killer가 필요한 상황이 발생하는 것입니다. 이러한 정책을 optimistic memory allocation이라고 부르구요. (반대로 pessimistic이 있겠죠)
Linux는 ‘프로세스는 자신이 요청한 메모리 양을 모두 쓰지 않는다’라는 낙관적인 가정을 하기 때문에 이렇게 부릅니다.
Linux는 최대한 할당은 늦게 하고, 한번 할당되면 계속 사용한다는 가정을 하고 VM 시스템을 만들었습니다.
brk() system call을 통해서 heap 크기를 늘리려고 시도할 때 (즉, virtual address space를 할당할 때)는 일단 허용하고,
실제로 memory frame이 할당되는 시점을 사용자 프로세스가 실제로 해당 메모리에 접근해서 fault가 일어날 때로 미루어서 이러한 정책을 구현합니다.
물론 OS는 사용자 프로세스들에 할당된 address space의 총합과 자신이 할당할 수 있는 memory frame의 전체 크기를 알기 때문에 overcommit을 방지할 수 있습니다.
Linux 2.6에서도 가능한 것 같습니다. /proc/sys/vm/overcommit_ratio를 조정해서, 둘 사이의 비율을 조정할 수 있습니다.
root@www src # uname -a
Linux www.lastmind.net 2.6.8-rc1 #1 Thu Jul 15 21:11:46 KST 2004 x86_64 4 GNU/Linux
root@www src # cat /proc/sys/vm/overcommit_ratio
50
이러한 정책은 어떻게 보면 매우 비합리적으로 보일 수도 있지만, 성능을 올리는데 효과가 있다고 합니다.
(예를 들어, 프로세스 fork시의 COW 정책도 일종의 overcommitting이라고 하는군요.)
OOM killer is …bad guy?
http://www.kerneltraffic.org/kernel-traffic/topics/OOM_Killer.html
kerneltraffic쪽의 page들을 보면, OOM killer가 a)와 b) 단계에서 사용하는 algorithm들에 문제(버그?)가 많았던 모양입니다.
특히 b)의 경우에는 heuristic일 뿐이라서, 중요한 프로세스와 아닌 프로세스를 구분하지 못하기 때문에,
데스크탑 환경이 아닌 서버 환경에서는 매우 치명적일 수 있습니다. 그 외에도 deadlock 같은 버그 문제도 보이는군요.
그래서 그런지 2.4.23에서 OOM Killer는 빠졌습니다만,
http://www.kerneltraffic.org/kernel-traffic/kt20031214_245.html#6
http://kerneltrap.org/node/view/1010
http://kerneltrap.org/node/view/1017
http://kerneltrap.org/comment/reply/1754
다시 그 필요성 때문에, 2.4.24-pre1에서 OOM killer를 kernel compile option(CONFIG_OOM_KILLER)의 형태로 추가했다고 합니다.
문제들은 계속 수정되는 것 같습니다만, b) algorithm이 heuristic라서 발생하는 문제는 여전한 것 같습니다. ^^;
debian의 kernel-image-2.4.26-1-686-smp의 image는
CONFIG_BINFMT_MISC=m
# CONFIG_OOM_KILLER is not set
CONFIG_PM=y
와 같이 OOM killer가 기본적으로 꺼져있군요.
OOM killer algorithm
mm/oom_kill.c를 보면 OOM killer의 코드가 나옵니다.
* The routines in this file are used to kill a process when
* we’re seriously out of memory. This gets called from kswapd()
* in linux/mm/vmscan.c when we really run out of memory.
kswapd는 kernel thread로 동작하면서, page cache를 유지하고 slab cache를 shrink하고 swapping out을 수행합니다.
http://www.csn.ul.ie/~mel/projects/vm/guide/html/understand/node68.html
a) zone마다 일정 수(pages_high)만큼의 page를 확보하기 위해 try_to_free_pages_zone()을 호출하는데,
shrink_caches()를 호출해서 128K 정도의 메모리를 확보하려고 합니다.
http://www.csn.ul.ie/~mel/projects/vm/guide/html/code/node38.html#SECTION001030200000000000000
이를 수행하지 못할 경우, oom_kill.c의 out_of_memory()를 통해, oom_kill()이 수행됩니다.
이는 physical memory를 swap할 공간도, cache를 shrink할 공간도 없다는 의미입니다.
b)
oom_kill()은 모든 task에 대해 badness()를 계산해서 가장 나쁜(badness()의 결과가 가장 큰) task를 kill합니다.
badness()의 주석을 보면,
/**
* oom_badness – calculate a numeric value for how bad this task has been
* @p: task struct of which task we should calculate
*
* The formula used is relatively simple and documented inline in the
* function. The main rationale is that we want to select a good task
* to kill when we run out of memory.
*
* Good in this context means that:
* 1) we lose the minimum amount of work done
* 2) we recover a large amount of memory
* 3) we don’t kill anything innocent of eating tons of memory
* 4) we want to kill the minimum amount of processes (one)
* 5) we try to kill the process the user expects us to kill, this
* algorithm has been meticulously tuned to meet the priniciple
* of least surprise … (be careful when you change it)
*/
주석을 좀 이상하게 적어놓은 것 같은데, 죽이기에 좋은(Good) task가 kill할 task가 됩니다.
이러한 알고리즘에 따르면,
기본적으로 적은 수의 프로세스를 죽여서 많은 양의 메모리를 확보할 수 있는 heuristic을 쓰는 것을 알 수 있습니다.
3번에서 메모리를 많이 사용하는 innocent는 죽이지 않는다고 했으나,
실제 코드를 보면, 여기서 innocent란, 단순하게 cpu를 많이 사용하는 프로세스를 의미하는 것 같습니다.
또한, super user process이거나 hardware를 access하는 경우 badness point를 1/4로 삭감해줍니다.
Solution
OOM killer가 heuristic에 기반하고 있기 때문에, 중요한 server process가 죽지않는 다는 보장을 하기가 힘듭니다.
(위의 badness() 값을 낮추는 방법들을 전부 쓰더라도)
하지만, OOM killer를 쓰지 않는다고 하더라도, 특정 프로세스가 종료할 때까지 기다리는 수 밖에 없고,
(malloc으로 할당 받은 메모리는 대체로 다시 반납하지 않습니다.)
page fault handler에서 page frame을 할당받지 못하면, init를 제외한 해당 task는 kill 되기 때문에,
OOM 상황에서는 어차피 치명적인 상황이 발생합니다.
따라서, OOM 상황이 발생하지 않도록 노력하는 것이 중요할 것 같네요.
server 어플리케이션의 경우에는 대체로 자신이 사용하고 있는 메모리 양을 알고 있으므로 이에 대한 제약을
어플리케이션 수준 또는 시스템 수준(ulimit)에서 가하는 것도 괜찮은 방법이라고 생각합니다.
그리고 메모리 바운드 어플리케이션이라면 대부분 swapping out 되는 것을 원하지 않을 것이므로,
page에 lock을 거는 방법을 생각해볼 수도 있겠네요. (physical page frame이 부족할 경우, 자동적으로 실패하겠죠)
Extreme Programming Explained: Embrace Change
XP의 창시자인 Kent Beck이 쓴 XP에 관한 책이다. XP를 공부할 때 처음으로 읽어야할 책이 바로 이 책이다. 200 페이지도 채 안되는 분량의 책은 매우 잘 쓰여진 책이다. 맨 먼저 해결하려는 문제를 정의한 후, 문제에 관련된 변수들을 파악한 후, 추구하는 가치와 기본 원리를 설정한 후 (문제의 해결방법에 있어서, 서로 충돌하는 가치가 있을 때 중요한 단계이다), 이 가치를 달성하기 위한 방법을 제시하고, 이 방법을 실제로 적용할 때의 이슈를 논의한다. 책에서만이 아니라 실제 문제에 있어서도 이러한 접근을 하면, 쓸데없는 혼란을 야기하지 않고 문제를 해결할 수 있다. 또, 자신만의 문제를 해결하기 위해서 뿐만이 아니라 다른사람과 문제와 해결책에 관해 커뮤니케이션할 때도 유용한 패턴이라고 볼 수 있다. (가끔씩 주변을 보면, 문제를 정의하지 않고도 해결법을 찾으려고 하거나, 문제를 알려주지도 않고 해결법을 제시하는 사람들을 볼 수 있다. 선문답이 되면 행복한 케이스지만, 동문서답이 되면 곤란하다.)
다시 XP 얘기로 돌아가서, Kent Beck이 제시하는 소프트웨어 개발 프로젝트의 문제는 바로 Risk이다. 즉, 스케줄의 변경, 프로젝트의 취소, 소프트웨어 결함, 요구사항 변경, 리소스 변경 등이 소프트웨어 실패의 가장 큰 원인이란 것이다. (경험적으로, 이에 전적으로 동의한다) 그렇다면, 우리가 이걸 해결하기 위해서 무엇을 할 수 있는 가를 봐야할 것이다. Kent Beck은 소프트웨어 개발 프로젝트의 ‘Four Variables’로 Cost, Time, Quality, Scope를 제시한다. 일반적으로 Cost와 Time은 우리가 control 하지 않고, (이른바, ‘기획’하는 사람들이 control한다) Quality는 control하기에 너무 어려운 변수이기 때문에, Kent Beck은 Scope에 집중하겠다고 얘기한다.
XP의 네가지 가치(Four Values)는 바로 Communication, Simplicity, Feedback, Courage이다. 기본 원리에는 좀 더 여러가지가 있다. Rapid feedback, Assume simplicity, Incremental change, Embraching change, Quality work.
XP의 해결책이 되는 practice들은 비교적 잘 알려져있다. The Planning Game, Small releases, Metaphor, Simple design, Testing, Refactoring, Pair programming, Collective ownership, Continuous integration, 40-hour week, On-site customer, Coding standards. 이러한 practice는 XP에서 새로 발명한 practice들이 아니라 기존의 Software engineering에서 강조하는 것을 radical하게 강조한 것이다. 다시 말해, code review가 좋은 practice라면 항상 하자는 것이 바로 pair programming이고, simplicity가 좋다면 가장 simple한 design을 하자는 것이 Simple design이라는 식이다. 우리나라말로 하면 좋은 게 좋은 것 정도가 될까? 바로 이러한 아이디어가 ‘Extreme Programming’의 어원이라고 한다.
개인적으로는 Simplicity와 Simple design이 가장 인상적이었다. 물론 현업(-_-;)에 가장 적용하기 쉬운 것이고, 스스로가 ‘design for tomorrow’에 의한 폐해를 많이 겪었기 때문이었다. XP 책을 읽기 전에 이미 약간은 이 practice를 적용해보았고, 결과는 매우 좋았던 것 같다. 개인적인 습관 때문인지 자꾸 복잡한 디자인을 하려는 경향이 있긴 하지만… 계속 remind하고 마인드 트레이닝을 할 필요가 있을 것 같다. 아, 그리고 개인적으로는 기획과 개발이 분리된 job을 그다지 많이 하지 않았기 때문에, 직접 경험한 적은 별로 없지만, 주변 사람들이 자주 불평하는, 기획이 계속 requirement를 변경하거나 기획과 개발의 경계가 불명확한 경우의 괴로움을 XP는, 깔끔하게 해결하고 있는 것 같다. Planning Game을 통한 role의 명확한 분리와 Small release로 인한 risk의 감소가 바로 그것이다. Shared code ownership도 매우 좋은 practice이긴 하지만, 실제 우리 팀에서는 중간 정도의 형태를 취하고 있는 것 같다. product의 경우에는 따로 ownership을 가지고 공유하는 라이브러리의 경우에는 shared ownership 정도가 되는 것 같다. 이렇게 되면 갑자기 다른 사람이 고쳐서 동작하지 않는다는 등의 약간의 리스크는 있지만, Testing으로 극복을 할 수 있도, 이 때에 얻는 개발 속도의 장점은 매우 큰 것 같다. 그리고 On-site customer도 회사에서 자주 보는 communication overhead를 상당히 줄여줄 것 같은데, 우리나라에서 자주 보이는, 팀 간의 알력이 강하게 존재하는 조직 구조에서는 실현하기가 상당히 힘들 것 같다. 더구나 manager들이 깨어있고, 같은 이익을 향해 달려간다는 마인드를 가질 수 있으려면 조직의 크기가 클 수록 불리한 반면, 충분한 인력을 확보할 수 없는 작은 조직의 회사라면 다시 불리한 면도 있는 것 같다.
Agile software development methodology가 상당히 유행하고 있는데, XP가 아닌 다른 방법론 – FDD 등의 방법론들도 한번 살펴보고 싶다.
Understanding the Linux Kernel (2nd Edition)
영문판이 아니라 한글판을 읽고 있다. 2.2 버전을 다룬 1판을 사둔 채 버려두고 있다가 2.4 버전을 다룬 2판도 역시 묵혀오고 있다가, 추석 때 집에 내려가서 읽기 시작했다. 내용은 말그대로 리눅스 커널의 구현에 대한 내용으로, 특히 x86 계열에서의 구현에 집중하고 있다. (때문에 x86에 관한 내용도 꽤 나온다.)
현재, 1장의 introduction을 읽은 후, VM 파트를 따라서 2장, 7장을 읽고 8장을 읽고 있는 중이다. 2장 ‘메모리 주소 지정’은 IA-32 매뉴얼에도 나오는 x86 시스템에서의 segmentation, hardware paging, cache, TLB 등을 다루고 있다. 모호하게 이해하고 있던 부분을 (특히 OS 레벨인지 하드웨어 레벨인지의 구분, ‘logical address’와 ‘linear address’의 용어 구분) 말끔하게 해소한 것 같다. 7장은 커널 상의 메모리 관리를 다루고 있다. physical memory와 linear address space의 관리를 다루고 있다. 8장은 커널이 아니라 사용자 프로세스에게 할당되는 메모리를 다루고 있다. 아마도 프로세스에게 할당되는 linear address space의 관리와 page fault handling을 통해 page frame (physical memory)을 할당하는 방법을 다루고 있다. 여기까지 읽은 후에는 3장으로 돌아가서 프로세스에 대한 내용을 읽을 생각이다.
약간의 번역 inconsistency가 눈에 띄지만 (용어의 번역 여부 e.g. TLB/변환참조버퍼) 번역 퀄리티는 만족스러운 편이며, 내용도 어느 정도 OS에 관심을 갖고 있던 사람이라면 그리 어렵지는 않은 정도. 침대 머리 맡에 놓고, 자기 전에 살짝 조금씩 봐주고 있다. 시스템 프로그래머의 길을 간다면 커널의 이해는 거의 필수적이므로 이를 위해 볼만한 책 중의 하나 일 것 같다.
참고를 위해 언급하자면, 물론 다른 고전적으로 유명한 책들도 있다. Bach의 The UNIX Operationg System (너무 오래된 감이 있음)이나 UNIX Internal (괜찮은 듯), The Design and Implementation of the 4.4 BSD Operating System (안봐서 모름), Solaris Internal (안봐서 모름).
물론 자기네 회사에서 나온 책이니 그렇겠지만, MSDN blog들에서 워낙 칭찬하던 책이라, 이 책을 처음 접하게 되었다. OOT에서 얘기하는 Object design의 기본적인 기법이나 pattern 같은 것들을 어느 정도 알고 있고, 또 사용하고 있지만, 내가 디자인한 OO 코드를 반대하는 사람에게 나의 디자인을 설득할 자신까지는 없었다고 할까. 기껏해야 OO에서 널리 쓰이는 기법이다 정도?의 argument로는 스스로가 납득할 수가 없었다. 따라서, 이 책을 산 목적은 Object-Oriented Technology의 역사/철학적인 백그라운드를 갖기 위해서였다. 실제로 이 책은 OOT의 역사와 철학, 용어들을 설명하는 non-formal한 OOT의 introduction book 정도로 생각하면 될 것 같다.
Preface, Introduction을 막 마친 상태인데, 11월까지는 끝낼 생각이다. 여기서 빠뜨릴 수 없는 얘기가 Preface/Introduction에서 이 사람은 범상치 않은 얘기를 하고 있다는 것이다. Preface에서는 Booch의 말을 언급하면서 OO란 decomposition에 대해 다르게 생각하는 방식/다른 가치/다른 문화라고 얘기한다. 이어서, formalism/Software engineering과 hermeneutics-postmodernism/XP/agile methodologies/behaviroal objects의 철학을 서로 대조하고 있다. Introduction에서는 Software crisis에 대해서 언급하면서 이를 해결하기 위해서 학계가 선택한 현재의 Software engineering은 process와 methodology에 주안점을 두었지만, 이는 현재 실패했다고 한다. 따라서, tool이나 process나 methodology를 만드는 것이 아니라, 원래 ‘Software Crisis’의 해결책으로 제시되었던 ‘Better people’을 만들어내야한다고 주장하고 있으며, 자신의 책이 ‘Better people’을 만드는 데 도움을 주는 책(중의 하나)이라고 주장하고 있다.
참고로, 얼마전에 slashdot에 review가 올라왔던 Organizational Patterns of Agile Software Development에서는 이렇게 얘기하고 있다.
What makes a software development project succeed? It’s not language or tools or process. It’s not a simple as people; even great programmers sometimes find themselves associated with disasters. In some sense, a successful project is the same thing as a successful organization; but what makes those? We need an anti-Dilbert. In Organizational Patterns of Agile Software Development, James O. Coplien and Neil B. Harrison lay out the results of their research on the subject; what they found, helps.
즉, 소프트웨어 개발 프로젝트를 성공하게 하는 건, 툴이나 프로세스도, 사람도 아니라 바로 조직이라고 얘기하고 있다. “Object Thinking”에서 주장하는 “사람”과는 또 다른 주장인 것이다. 누구 말이 맞는 것일까? 서로 다른 철학과 서로 다른 주장이 난무하는 이 분야는 아직 pseudo-engineering의 분야이다.
Extreme Programming Explained, Understanding the Linux Kernel, Object Thinking 더 읽기"
요즘 주위의 논쟁을 들어보니, 논쟁의 핵심인 이 결정문을 실제로 읽어본 사람이 거의 없는 것 같아서 링크합니다. 주변에서 ‘관습 헌법’ 만을 안주로 삼아서 비판하길래 좀 짜증이 나더군요. 이 결정문은, 성문헌법체제에서의 관습헌법의 의의 + (정체성의 의거한) 기본적 헌법사항으로서의 수도문제 라는 두가지 핵심 논지에 의해서 판단을 내리고 있지, 관습헌법만을 근거로 삼지는 않고 있습니다. 농담일 뿐인 얘기에 너무 민감하지 않느냐고 얘기할 수 있겠지만, 사실을 왜곡하는 농담은 비판하고 넘어갈 수 밖에 없습니다. (실제 자리에서 이런 얘기를 하면 무시당하기 일쑤입니다. 조심하시길.. ㅋ)
그리고, 더불어 전효숙 재판관의 반대의견 요지를 한번 읽어보세요. 정말 아이러니컬하게도, ‘재판관 전효숙의 반대의견 요지’가 이 결정문에서 가장 합리적인 논리인 것 같습니다.
http://www.ohmynews.com/articleview/article_view.asp?no=192822&rel_no=1