Arachneng on Everything

유행에 좀 뒤쳐진 감이 있지만 메아리에 서서히 HTML5를 적용하고 있다. 일단 저널에서 article, footer, hgroup 따위를 쓰게 바꾸고 메타데이터...

Thu, 29 Jul 2010 05:57:39 +0900

유행에 좀 뒤쳐진 감이 있지만 메아리에 서서히 HTML5를 적용하고 있다. 일단 저널에서 article, footer, hgroup 따위를 쓰게 바꾸고 메타데이터 정비하고… 하는 정도인데, 좀 제대로 들여다 봐야 겠다.

원래 HTML5는 인터넷 익스플로러 6이 망할 즈음에 적용을 하려고 미루고 있었지만 이번에 레딧에 영문 글도 올리고 하다 보니까 자바스크립트로 런타임에 메시지 번역을 할 필요성을 느꼈고, 그런데 그렇다고 다국어 메시지를 HTML 컴파일러 단에도 넣고 자바스크립트에도 중복으로 넣는 건 뭐해 보여서 생각하다가 HTML5의 data-* 속성이 생각나서(…) HTML5 적용을 날치기로 결정했다. 기본적으로 정적 HTML 파일로만 구성되는 메아리 메인의 특성상 전체적으로 적용하려면 먼저 저널 등에서 잘 도는지 확인하고 컴파일을 한 번에 해야 해서¹ 메인 사이트까지 전파되는 데는 좀 시간이 필요할 듯.

지금 보니까 문서 수가 벌써 300개다. 옛 블로그 글의 힘이 크리라… ↩

내가 카이스트에 몇 년동안 살면서 느끼는 건데, 카이스트 네트워크는 카이스트 이름값을 전혀 하질 못하는 것 같아. 내가 학교 네트워크에 무슨 six sigma 가용성을 요구하는...

Tue, 27 Jul 2010 03:39:00 +0900

내가 카이스트에 몇 년동안 살면서 느끼는 건데, 카이스트 네트워크는 카이스트 이름값을 전혀 하질 못하는 것 같아. 내가 학교 네트워크에 무슨 six sigma 가용성을 요구하는 것도 아니고 그냥 “조금 덜” 죽어 줬으면 좋겠는데, 아직도 학교 네트워크는 비만 오면 핑 로스가 눈에 띄게 늘어나고 덕택에 카이스트 FTP도 영향을 받았지. 무슨 니네가 항공업계냐? 폭우 오면 연착하게?

그래도 여기까지는 참을 수 있어. 뭐 비 오면 텔레비전도 잘 안 나오고 사람도 나른해지니까 뭐 그러려니 할 순 있다고. 근데 최근에 무슨 보안 소프트웨어 강제 설치한다고 윈도에서 브라우저 켜면 강제로 접속한 사이트를 프레임에 가두고 팝업을 띄우더라고? 그래서 팝업 차단을 걸면 팝업 안 열었다고 원래 사이트도 접속 못 하게 막고. 이게 무슨 짓이야, 나는 윈도에서 Avast! 깔아서 쓰는데 또 보안 소프트웨어를 깔라고? 심지어 방화벽도 내가 직접 설정하는데 그만 좀 띄우라고 내가 설정하면 그만 띄워 줄 수는 없는 거니? 응?

좋아, 여기까지는 내가 가급적이면 윈도에서 도메인으로 바로 접속하는 걸 피해서¹ 버틸 수 있었어. 하지만… 내가 기숙사에서 아래 글을 쓰다가 글을 한 번 날릴 뻔 한 적 있거든? 그게 하도 이상해서 좀 확인해 봤는데, 이렇게 나오더라.

…그러니까 지금 ||, from, 별표, set이 글에 순서대로 들어 가면 패킷을 친절하게 날려 준다는 거지?² 내가 SQL injection 공격 막는다고 서버 단에서 mod_security 따위 쓰는 건 봤어도 프락시에서 친절하게 막아 주는 미친 놈들은 처음 봤다. 그럼 내가 phpMyAdmin으로 외부에 데이터베이스 접속해서 관리하려고 하는데 저런 패턴이 들어 가면 날아가는 거야? 그런 거야?

아오썅 더 이상 못 참겠다. 내일 정보통신팀 두고 봐라. 내 소중한 다섯 시간을 이거 추적하느라 감쪽같이 날려 줬어. 개새끼들.

이 웃기지도 않은 소프트웨어 강제 설치 시스템은, http://domain.com/에 접속하면 자동 설치 ActiveX 및 팝업을 담은 프레임을 띄우고 실제 페이지는 http://domain.com/?으로 보여 줘서 동작한다. 그러니 최상위 주소를 안 사용하면 귀찮은 팝업을 많이 줄일 수 있다. ↩
참고로 이 “별표”를 실제 문자로 쓰면 이 글 자체가 저장이 안 된다. -_-; 원래 글에서는 from 중간에 태그를 끼워 넣고 set을 altered라는 다른 표현으로 바꿔서 피해 갔지만… ↩

Snowball Bugs

Mon, 26 Jul 2010 00:57:00 +0900

Mac OS X’s strftime(3) function has a significant problem with timezones. Intriguingly this very problem is traced back to FreeBSD and tzcode, from which the code in question originates, and due to this problem tzcode fails to process its companion database, tzdata! I’m going to report this bug anyway but it would make a good journal entry…

Start with tzdata. Tzdata is a public-domain timezone database used in the most operating systems including Linux, FreeBSD and Mac OS X. It is kept up to date, and it even tries to record even obscure historic timezone data: for instance you can see solar87 through solar89 files in tzcode, which reflects a Saudi Arabian policy of using mean solar time from 1987 to 1989. (To be exact, it is not in tzdata since it was too large and obsolete.) The ubiquity of tzdata means an error in tzdata file leads to the disaster.

FreeBSD libc chose to reuse tzcode to parse tzdata. It was in the public domain anyway and written by the same guy (Arthur David Olson) who founded the tzdata. Glibc also used the same code, but it was eventually deviated from the original code. And Mac OS X, or more precisely, Darwin picked up the code and slightly modified it to conform UNIX’03. The problem was, however, tzcode had a potentially wrong code. In Mac OS X:

$ TZ=Asia/Seoul date +'%Y-%m-%d %H:%M:%S %z %Z'
2010-07-26 00:36:24 +0800 KST
$ TZ=Asia/Tokyo date +'%Y-%m-%d %H:%M:%S %z %Z' 
2010-07-26 00:36:28 +0900 JST

You don’t need to look up the actual timezone of Korea and Japan to understand this bug. (Both countries use UTC+9, by the way.) But you can see the time and timezone are in disagreement, and in fact %z formatter is incorrect. This is caused by localtime.c (See FreeBSD version and Darwin version) in tzcode, which reads:

static void
settzname(void)
{
    /* snip */
    for (i = 0; i < sp->typecnt; ++i) {
        register const struct ttinfo * const ttisp = &sp->ttis[i];
        /* snip */
        if (i == 0 || !ttisp->tt_isdst)
            timezone = -(ttisp->tt_gmtoff);
    }
    /* snip */
}

A compiled tzdata file is a binary file, which consists of a list of (transition time, new timezone rule) pairs and a list of actual rules. For example if the country X changes a timezone from UTC+8:30 to UTC+9 by July 2010, the transition list will have a entry (2010-07-01, NewRuleID) and the rule list will have a entry (NewRuleID, +540 minutes, “X Standard Time”). While the rule list do not need to be sorted (the transition list has to be) the code above assumes the last non-daylight-saving rule is the most recent rule, but this assumption failed in Asia/Seoul timezone. If you have MySQL you can easily verify this fact by using mysql_tzinfo_to_sql command.¹

Tzcode originally altered the timezone variable only if System V compatibility option is on. But many programs do not rely on this variable due to its variability; in fact more robust but non-portable² way is to retrieve tm_gmtoff field using localtime(3). Therefore the bug was safely ignored in FreeBSD, but Darwin has modified its strftime(3) implementation to conform UNIX’03, which innocently replaced tm_gmtoff field with the current timezone, and exhibits this bug.

This weird bug seems to be first identified from the ruby spec test, since Ruby 1.8 has used the system strftime(3) routine. Personally I believed that the bug is Apple’s fault, but got a bit shocked when Olsen made the bug. So it is a snowball bug — if you cannot catch the bug at first glance, it would keep growing and hit someone else’s back.

Postscript: So did glibc avoid this bug? They did, and they show a reason that the complete rewriting is sometimes good. Well, not always good.

Update (2010-07-28): The fix for this bug is now available in tz list. I’ve also reported it to Apple.

The listing seems to make Tumblr crazy, so please see this pastie for now. While South Korea now uses UTC+9 (rule #1) and did not observe the summer time since 1988, it once used UTC+8 (rule #3) and UTC+8:30 (rule #0) before 1968. ↩
While this field is not a part of any standards, it is supported by BSD and glibc so the compatibility problem is actually not big. For Microsoft Windows, use GetTimeZoneInformation API call. ↩

…아는 사람은 알겠지만 아래 글은 IRC에서 누가 이 얘기를 꺼내길래 오후 11시 25분에 “이거 저널로 써야지ㅋ”라는 생각으로 쓴 것이다....

Sat, 24 Jul 2010 00:29:41 +0900

…아는 사람은 알겠지만 아래 글은 IRC에서 누가 이 얘기를 꺼내길래 오후 11시 25분에 “이거 저널로 써야지ㅋ”라는 생각으로 쓴 것이다. (뒤따르는 반응은 “근데 자정 얼마 안 남았는데?” “헐퀴”) 그런 고로 원래 쓰려고 했던 내용이 좀 빠져 있는데(…) 마저 쓰기로 하자…

옛날 언어 이름이 두문자어, 두문자어에서 유래한 이름(FORTRAN 따위를 생각해 보라) 또는 한 글자짜리 이름(…)이었던 반면, 요즘 언어 이름은 두문자어가 아니면서 적절한 의미를 가지는 이름이 폭발적으로 증가한 것 같다. 가장 큰 이유는 역시 “구글에서 검색했을 때 이것만 나와야 한다”라는 조건일테고¹ 그러면서도 읽기 좋아야 한다는 것일텐데, 안타깝게도(?) 짧은 이름을 가진 언어 이름은 이미 많이 선점된 상태라 최대한 창의성을 발휘해야 하는 것 같다. (난해한 프로그래밍 언어 중에 TMMLPTEALPAITAFNFAL이라는 거지같은 이름을 쓰는 경우는 있긴 한데…) 이보다 좀 더 어려운 문제를 고르자면 언어 소스 코드의 확장자가 있겠는데, 이를테면 내가 만드는 나루의 경우 일단 .n을 잡고 있지만 이 확장자는 사실 Nemerle에서 잘 쓰고 있는 확장자라 쓰기가 꺼려진다. 읔. 그냥 포기하고 .na를 쓸까.

비단 언어 이름 뿐만 아니라 프로젝트 이름을 정하는 데도 비슷한 문제가 있는 것 같다. 나 같은 경우 내부적으로 몇 개의 이름 풀(naming pool)을 만들어서 쓰고는 있는데² 프로젝트 성격과 아예 관계 없는 이름을 쓰는 것도 좀 애매해서 여전히 어려운 일로 남아 있다. 실제로 이번에 논문 쓰고 있는 주제는 QuickCheck를 Fortress에 포팅하는 얘긴데 (지금 생각해 보면 Fortress도 잘 지은 이름이다!) 창의적인 이름을 생각해 낼 수 없어서 결국 FortressCheck이라는 이름으로 귀결될 예정이다. 생각해 보니 스칼라쪽 포팅도 Scalacheck이었지만… orz

Googlability라고 해야 할까. 실제로 Go가 처음 나왔을 때 이 이름이 이미 사용되고 있다는 버그가 올라왔었는데 역설적으로 구글 안에서 googlability를 만족하지 않는 이름을 선택한 사례(…)가 되었다. 이 쪽은 엄밀히 말하면 “Go!”였지만. 어쨌든 덕택에 이 버그 번호를 따서 “Issue 9”라는 이름으로 바꾸자는 얘기가 한동안 돌기도 했다… ↩
예를 들어 norang, parang 류의 색깔 시리즈가 있는데, 어째 여기에 속한 프로젝트는 시작하는 족족 망하는구나. ↩

프로그래밍 언어 이름 A to Z

Fri, 23 Jul 2010 23:59:00 +0900

C 같이 이름이 한 글자인 프로그래밍 언어들에 대한 얘기가 KLDP에서 나온 적이 있었는데 이 참에 좀 제대로 정리해 보기로…

A: 일단 기괴한 문자 집합으로 유명한 APL(1964)이 원래는 A programming language이라는 책에서 출발했다는 건 유명. 또한 APL의 변종 중에 A+(1988)이 존재하고 이 언어가 옛날에는 A라고 불렸다고 한다. (A stands for “aggressive extensions”) 그 밖에 A++(2001), A#(Ada의 .NET 포트) 따위가 있다고.
B: C 언어의 선조격인 B 언어(1969)가 있다. 좀 더 말하자면 C 언어는 B에서 유래했고, B는 BCPL(1966)에서, 그리고 BCPL은 다시 CPL(1963)에서 유래했다.
C: 우리가 잘 알고 있는 C 언어(1972). 여기서 유래한 언어들이 C에 뭔가 기호를 막 붙인 경우가 꽤 있는데 이를테면 C++(1983), C--(1997; GHC의 저수준 IL 등으로 쓰임), C#(2001), Cω(2003, C#의 concurrent extension) 따위가 있다. 왠지 C@ 같은 것도 보이지만 눈의 착각이겠지…
D: 이 이름을 가진 언어가 몇 개 있지만 가장 널리 알려진 것은 월터 브라이트의 D 언어(1999)일 것이다. 이 언어는 C++의 reengineering으로 시작되었다.
E: 왠지 Erlang이 생각나는 이름인데 사실 이 이름을 가진 E 언어(1997)가 실제로 distributed computing을 위한 언어이다. 같은 이름을 가진 하드웨어 검증 언어(1992)도 있다.
F: Fortran 95의 부분집합으로 정의된 F 언어가 존재한다. 하지만 ML의 .NET 포팅인 F#(2002)가 이 쪽에서는 더 유명하지 않을런지.
G: LabVIEW(1986)의 원래 이름이 G(“graphical” language라서 그런 듯)였다고 한다.
J: 일단 APL의 후손인 J 언어(1990)가 존재하고, 마이크로소프트에서 만든 자바 계열 환경 및 언어인 J++과 J#(2002)도 있다.
K: 마찬가지로 APL의 후손인 K 언어(1993)이 여기에 속한다.
L: 위키백과에 따르면 이 이름을 가진 언어들이 꽤 있다고 하는데 (TCL 계열 언어도 하나 있고, distributed language도 있고, C++의 확장도 있다) 별로 들어 본 기억이 없다.
M: 포트란만큼이나 오래된 MUMPS(1966) 언어를 M이라고 보통 많이 부른다. (이 언어의 이름이 진짜로 뭐인지에 대해서는 여전히 논란이 있는데, 표준화 과정에서는 MUMPS라고 했다.) 한편 마이크로소프트의 오슬로 프로젝트에서 사용하는 M 언어(2008)도 있다.
P: 난해한 프로그래밍 언어 계열 중에 P(2005)라는 이름을 가진 게 있다. 또한 Brainfuck(1993)과 거의 똑같은 계산 모델인 P”(1964)도 있다. (그러나 이 유사성은 순전히 Brainfuck이 너무 단순해서 그런 거지 실제로는 Brainfuck 쪽에서 영향을 받은 건 아닌 것 같다.)
Q: Term rewriting을 기반으로 만들어진 함수형 언어 Pure(2008)의 옛 이름이 Q였다. 놀랍게도 Q는 “eQuational”에서 나왔다고… 그 밖에 K에서 유래한 APL 계열의 언어(2003)도 같은 이름을 가진다.
R: 통계 분야에서 많이 쓰이는 R 언어(1993)가 여기에 속한다. 특허 때문에 망했다는 전설의 R++ 언어도 있다.
S: 앞에서 말한 R 언어가 원래는 S 언어(1975)의 현대적인 버전으로 출발했다. (당연히 S는 Statistics의 약자일 듯… 왜 이름이 이따구야.)
T: 스킴(1975)의 구현을 테스트하기 위한 목적으로 만들어진 언어가 T 언어였다고 한다. 스킴과 다른 점은 객체지향적이고(CLOS를… 끼얹나?) 느긋한 계산법을 일부 지원한다고.
U: TinyMUD 계열의 머드 구현체 중 UberMUD라는 것이 쓰는 스크립팅 언어(1990?)가 이 이름을 가진다고 한다. (이름 하나 정말 더럽게 못 짓는다.) 그런데 이거 말고 뒤지다 보니까… 글쎄 이런 게 나오더라!
V: 난해한 프로그래밍 언어 계열에서 V(2007?)랑 V—(2007)라는 이름을 가진 게 있긴 하다. 구글 코드를 뒤지니 결합형 언어 하나가 튀어나오기도 하는데, 많이 쓰이는 이름은 아닌 것 같다. 그리고 한 글자 이름은 아니지만 Vvvv(1998)라는 이름의 언어도 있다(…)
W: 이 이름을 가진 잘 알려진 언어는 없지만, 이것 같이 그나마 언어 스럽게 생긴 것들이 존재하기는 한다.
X: C# 계열의 임베디드 언어 이름 중 X++라는 것이 있다고 한다. ~~역시 JVM/CLR의 목표는 언어 갯수를 폭발적으로 늘리려는 것임이 틀림 없어~~
Y: SIGPLAN에 이 이름을 가진 언어(1981)가 등장했었던 모양. 난해한 프로그래밍 언어 중에서도 하나 눈에 띈다.
Z: 일단 Z 표기법(1977)이라 불리는 명세 언어가 존재하고 (어떤 의미에서는 강력한 선언형 언어로 볼 수 있을 듯), FOLDOC에 따르면 시뮬레이션 언어 중에서도 같은 이름을 가진 게 있다고 한다.

대강 찾아 봤을 때 안 나오는 이름은 H, I, N, O, X 정도였다. 어차피 구글에서 검색하기도 힘든데 이런 이름은 피하는 게 좋을 듯.

요즘 들어서 위키백과(엔진)와 엔하위키(분위기)의 영향을 심하게 받은 백과사전 위키들이 심하게 늘어나고 있다는 느낌이 든다. 나는 오락실 위키나 토끽누 위키1 같이 특정 주제에...

Mon, 19 Jul 2010 15:40:00 +0900

요즘 들어서 위키백과(엔진)와 엔하위키(분위기)의 영향을 심하게 받은 백과사전 위키들이 심하게 늘어나고 있다는 느낌이 든다. 나는 오락실 위키나 토끽누 위키¹ 같이 특정 주제에 특화된 위키가 만들어지는 건 긍정적으로 생각하는데, 문제는 스레디키나 자유인사전 같이 굉장히 어중간한 목적을 가진 사이트들도 존재한다는 거다. (물론 소속 사이트들에 대한 문서가 많이 올라오긴 하지만 일반 목적의 글들도 많이 올라 오고 있다.)

공동 참여를 목표로 한다면 명확한 목표가 있어야 한다는 게 내 생각이다. 스레디키는 스레딕에서 일어나는 사건이나 용어 중심으로 정리하고 아닌 것들은 위키백과나 엔하위키로 soft redirection을 해도 충분한 것이다. 자유인사전도 마찬가지고 (이 쪽은 내가 그 커뮤니티의 분위기를 몰라서 사실 잘 모르겠다). 내가 가장 우려하는 사태는 엔하위키 같은 목표를 가진 사이트가 여러 개 나타나서 각자 중복된 정보를 미친듯이 올려대는 건데, 다행(?)히도 이들 사이트들의 규모가 아직은 작아서 그걸 염려해야 할 정도는 아닌 듯 하지만 걱정되는 건 어쩔 수 없다. 그런 주제에 문서 수 700을 넘으면 위키백과 위키 목록에 등재될 수 있다²라는 황당한 얘기가 나오고 있으니… 어쩌란 말이냐.

…는 링크는 안 걸었지만 전 국민의 인터넷 스토커화를 앞두고 있는 대한민국에서는 누구나 찾아 낼 수 있으리라 의심치 않습니다. ↩
일단 위키백과의 문서 갯수 순 목록은 백과사전적 내용이 아니고 (오로지 참고용), 어차피 위키백과의 “저명성”이라는 개념이 페이지 갯수와 완전한 상관 관계를 이루는 게 아니므로 이런 수치는 무의미하다. 상식적으로 생각해 볼 때 페이지 갯수만으로 위키백과 등재가 가능했으면 문서 수가 1만개를 넘는 프리필은 왜 등재가 안 되었겠는가? ↩

…이제 리플즈 양민이라는 개드립은 더 이상 칠 수 없게 되었구나. 평균 98.5만점에 그레이드 포인트...

Sat, 17 Jul 2010 03:18:00 +0900

…이제 리플즈 양민이라는 개드립은 더 이상 칠 수 없게 되었구나. 평균 98.5만점에 그레이드 포인트 100만점 넘었으면 어지간히도 했네. 하지만 오락실 가던 도중 안경테가 부러져서 안경 안 쓰고 유비트 한 건 안 자랑. (그러나 엑설 세 개 새로 띄운 건 자랑.)

넷북으로 애니를 보는 정신 나간 사람이 나 말고 더 있는진 모르겠지만, 하여튼 최근 들어 온 영상들 중 H.264 1280x720 영상이 간혹 모션이 많은(이를테면 꽃가루...

Wed, 14 Jul 2010 00:43:51 +0900

넷북으로 애니를 보는 정신 나간 사람이 나 말고 더 있는진 모르겠지만, 하여튼 최근 들어 온 영상들 중 H.264 1280x720 영상이 간혹 모션이 많은(이를테면 꽃가루 흩날리는…) 부분에서 굉장히 많이 끊기는 것을 발견, 좀 고심하던 끝에 VLC에서 loop filter를 선택적으로 끄도록 했더니¹ 일단은 볼만한 수준으로 회복되었다.

최근 나오는 영상들은 모두 1280x720 아니면 1440x1024이고 그보다 더 작은 해상도는 (애니에서 많이 보이는) 얇은 선에 대한 처리가 도저히 참을 수 없을 정도라서 못 보겠더라. 그래서 선택한 결정인데 CPU 좀 적게 먹는 거 같아서 일단 만족 중. 물론 데스크탑 쪽 VLC 설정에서는 절대 이렇게 안 하겠지만…

디코딩 과정의 후처리 필터로 사용하지만 꼭 필요한 것은 아니고, 단지 깍두기(즉, macroblock들끼리 서로 나뉘어 보이는 현상)가 나타날 가능성만 높아질 뿐이므로 정 성능에 문제가 있으면 꺼도 된다. 나는 keyframe만 적용하도록 했다. ↩

soojung 보안 버그

Tue, 13 Jul 2010 14:19:00 +0900

설마 아직도 soojung을 쓰는 사람이 있을까 싶지만… 그래도 몇 사람 쓰고 있는 것 같으니까 공지. soojung의 현 버전(0.4.14)은 너무 오래 되어서 몇 가지 문제가 있는데 그 중 하나가 soojung의 XMLRPC 라이브러리 버전이 너무 낮아서 (1.2.1) 알려진 보안 버그가 있다는 겁니다. 가급적이면 xmlrpc.php 자체를 삭제하시거나, 나는 죽어도 metaWeblog API를 써야 겠다라고 하시는 분은 수동으로 libs/xmlrpc.inc랑 libs/xmlrpcs.inc를 1.3.2 이후 버전으로 업데이트해 보시길 바랍니다. (후자는 나도 안 해 봐서 되는진 모름)

이 보안 버그를 알게 된 건 루리넷이 이 버그로 실제로 공격을 받았기 때문이다. 그렇다. 이번에는 내 실수다. orz (애초에 soojung으로 된 블로그들을 모두 메아리로 이전하고 있긴 하지만, 아직 못 옮긴 블로그는 댓글 기능만 날린 채 그대로 soojung으로 운영한 탓이다.) 다행히 몇 시간동안 일부 사이트가 이상한 오류를 내뱉은 거 빼고는 별다른 문제는 없었다.

서버에 문제가 있다는 걸 알게 된 건 서버 사용자 중 한 사람이 자기 쓰던 도쿠위키에서 세션 에러가 난다고 한 것 때문이었다. 이 때가 대략 오늘 정오 쯤이었는데, 메시지가 딱 보니 /var 파티션이 꽉 찬 거라서 “아… 저번에 로그 지웠는데 또 왜 이러냐” 하는 생각으로 로그 디렉토리를 확인해서 6개월 넘은 로그를 모두 지워줬다. (하는 김에 logrotate 설정도 고쳤다. 웬만하면 배포판 설정 안 바꾸고 싶었는데 파티션이 너무 작아서…) 그리고 df 하니까 잘 지워진 것 같아서 안심하고 있었는데 똑같은 문제가 남아 있자 다시 한 번 df, 이럴수가! /var 파티션이 그새 다시 차 버렸다!

로그 디렉토리를 다시 확인하니 error.log가 2기가 넘는 용량을 자랑하면서 버티고 있길래 “이거 누가 쟝고에서 에러 세례를 퍼 붓고 있는 건가”(최근 쟝고 어플리케이션 올려 달라는 얘기가 좀 있어서;)하면서 지웠는데 df에서는 전혀 갱신되는 기색이 없었다. 아파치를 껐는데도 똑같은 문제가 발생하니까 이건 뭔가 다른 엉뚱한, 아마도 외부에서 올라온 프로그램이 문제를 일으켰으리라 생각하고 확인해 보니까 정말로 /tmp/ns1이라는 파일이 CPU를 다 잡아 먹고 있었다. 생각해 보면 뭔가 이상하다 느꼈을 시점에서 lsof를 먼저 했어야 하는 것 같긴 한데… 서버가 사용자들의 기괴한 사용으로 엉망이 되는 일은 흔한 일이라 잠시 부주의하고 있었다. 어쨌든 일단 kill하고 아파치 다시 재시작하니 df는 정상.

분명 제로보드는 수동으로 패치하고 그 밖의 프로그램들도 꽤 주의깊게 모니터링하고 있는데 어디서 공격이 들어 온 건지 생각하면서 이 파일의 정체를 확인해 보았다. stat 결과 파일이 만들어진 시각은 오늘 새벽 3시 10분 15초였고, 웹서버 계정(www-data)으로 만들어졌으므로 뭔가 PHP 셸 같은 게 돌아가다가 실행 파일을 올린 게 확실했다. 이미 프로세스를 꺼 버린 상태였으므로 이 프로그램의 정체를 확인하기는 쉽지 않았지만, error.log의 에러 메시지(아마도 stderr로 가야 할 게 이 쪽으로 재지정된 걸로 보인다)를 볼 때 뭔가 bind를 한 뒤 recvfrom을 하려다가 포트가 막혀서 에러 메시지를 뿜어 댄 것으로 추측되었다. 그래서 error.log가 10분만에 2기가를 넘은 게지. 그래서 그냥 맘 잡고 분석하기로 하고 objdump로 간단한 디스어셈블리를 해 보니 bind하는 포트는 UDP 포트 27444였고, Trinoo slave로 확인되었다.

아파치 에러 로그는 날렸으므로 확인할 수 없었지만, 액세스 로그를 확인해 본 결과 (다즐링 님의 조언으로) 93.69.44.202라는 아이피가 http://sapzil.info/soojung/xmlrpc/server.php로 여덟 번의 POST request를 보낸 것으로 확인되었다. (본래는 xmlrpc.php여야 겠지만 mod_negotiation이 활성화되어 있어서 /xmlrpc도 먹혔다. 그냥 운이 나빴던 듯.) 이 중 일곱번째 request가 response 크기가 다른 것과 서로 달랐는데 이 response 시점이 3시 10분 24초, 그러니까 파일 생성 9초 후여서 아마 이 request가 파일을 생성하고 실행했으리라 추측했다. 확인 결과 soojung의 XMLRPC 라이브러리에 버그가 있었고, 결국 나는 그냥 xmlrpc.php를 깔끔하게 지워서 (어차피 쓰지도 않는데) 문제를 일단 해결했다. 해당하는 아이피는 프락시인 것 같은데 더 이상 추적하긴 쉽지 않고, 주소로 추정할 때 나한테 원한 산 사람이라기보다는 그냥 무작위로 URL을 넣다가 운이 나빠서 걸린 것으로 보이기 때문에 보안만 강화하는 수준으로 하기로 했다. -_-;

나중에 루트킷도 확인해 보고 이런 저런 검사를 해 보기는 했지만 별 문제는 없는 것 같아서 모니터링만 꾸준히 하는 수준으로 마무리짓기로 하긴 했지만, 남들한테 제로보드 4 제발 쓰지 말라고 읍소하고 서버에 깔려 있는 모든 소프트웨어의 목록(이를테면 미디어위키 네 다섯 개라거나…)을 기억하고 있는데도 실수하는 걸 보면, 답은 명확하다. 오래된 소프트웨어는 쓰지 말자. orz

방금 전에 올린 글에 이어서 스크린샷 투척 2편. 윈도에서 VLC로 애니를 배경에 틀어 놓고(소리만 듣는 용도)...

Mon, 12 Jul 2010 01:09:22 +0900

방금 전에 올린 글에 이어서 스크린샷 투척 2편. 윈도에서 VLC로 애니를 배경에 틀어 놓고(소리만 듣는 용도) 전체화면으로 게임을 하고 있었는데 갑자기 죽어버리길래 mplayer로 바꿔서 틀어 보니… 이렇게 나온다.

아마 게임이 실행중이라서 DirectX 컨텍스트 생성이 실패했고¹ mplayer에서 대체 드라이버로 libcaca를 선택해서 보여 준 모양이다. -_-; 주변에서 구경하던 사람들이 이걸 보고 모두 황당해 하더라… 굳이 게임 따위 실행시키지 않고 테스트해 보려면 -vo caca 옵션을 줘서 테스트해 보시라.

최소 화면으로 틀어 놓은 상태에서는 창이 안 보이기 때문에 컨텍스트가 lost되어도 상관 없는 것 같은데, 다음 동영상이 시작될 시점에서는 최소 화면 상태라도 일단 컨텍스트를 생성하고 보는 것 같다. 아무래도 VLC 쪽에서 어중간하게 에러 처리를 한 듯. ↩

현금 영수증 사이트에 가서 사용 내역 조회를 하려고 했는데 매 화면에서 이 따위 공지가 나오고 있다....

Sun, 11 Jul 2010 23:07:19 +0900

현금 영수증 사이트에 가서 사용 내역 조회를 하려고 했는데 매 화면에서 이 따위 공지가 나오고 있다. …다 좋은데, 왜 “예”와 “아니오”를 묻는 사용자 인터페이스에 “확인”만 있는 게냐?!

(덤: 결국 조회 결과는 소득이 없었다. 꾸준히 친척 전화번호로 영수증 등록하고 내 걸로는 등록 안 하는 걸 까먹고 있었…)

크레올이냐 마크다운이냐

Thu, 08 Jul 2010 00:14:50 +0900

레딧에서 누가 위키크레올이 좋다고 하는 얘기를 듣고 이런 반박을 써 냈는데, 이왕 하는 김에 좀 더 반박을 해 보자. (제목이 어째 미안하게도 이전 글과 비슷하게 되었다…)

레딧에 썼듯, 마크다운이 다른 수많은 위키 문법들(특히 크레올)을 발라 버리는 이유는 몇 가지가 있다.

플레인 텍스트에 가깝다. 적어도 영어권에서 자주 사용하는 _emphasis_나 *emphasis* 같은 문법이 곧바로 지원되고, 총알 목록(bullet list, 그러니까 순번이 없는 목록)에서 총알에 무슨 글자를 써야 하는지 고민할 필요도 없다.
그러면서도 처음 봤을 때 모호함이 많지 않다. 예를 들어 내가 지적한 링크 문법¹은 사실 링크 텍스트와 링크 주소 간에 대칭성이 없어야 비로소 해결되는 문제인데 [text](url) 문법은 이 조건을 충분히 만족된다.
이건 순전히 구현체의 문제긴 하지만, 마크다운은 수많은 구현체가 존재하는 반면 대부분의 위키 문법은 그 문법을 구현하는 하나의 위키 엔진만이 구현체가 된다. 심지어 표준화를 한답시고 만든 크레올조차 일부 위키에서 “선택적”으로 지원할 뿐이다. (나는 기본적으로 탑재가 되어 있지 않으면 이런 종류의 표준화가 전혀 쓸모가 없다고 본다. 예를 들어 크레올 쪽에는 도쿠위키가 크레올 지원을 한다고 쓰여 있으나, 사실 문법 플러그인 하나 달랑 있을 뿐이고 popularity 보면 알겠지만 사용하는 곳도 별로 없다.)

물론 이럼에도 불구하고 마크다운이 지적받는 몇 가지 문제가 있긴 하다. 공평하게 말하자면, 마크다운은 다른 위키 문법보다 좀 나은 편이지 최적의 문법은 아닌 것이다. 이를테면:

확장에 부적합하다. 이는 마크다운 기본 문법 및 많이 쓰이는 확장들이 이미 상당히 많은 수의 좋은 특수문자를 잡아 먹은 덕택에 남은 특수문자라는 것이 @, & 같은 일반 텍스트에서 많이 나올 법한 것들 밖에 없기 때문이다. 마크다운 오리지날 버전은 이 문제를 HTML 문법을 그대로 쓰는 방법으로 피해 가려고 했던 것 같지만, 전혀 상식적인 발상이 아니다. (그럼 유튜브 동영상 넣고 싶으면 object 태그 다 넣을래?)
공백 문자에 지나치게 의존한다. (이 문제를 잘 설명하는 좋은 예로 크레올 측의 예시를 보시라. 이 쪽은 공백은 아니지만.) 특히 뒤에 공백 두 개 넣으면 줄바꿈이 되는 문법은 마크다운 문법에서 최악의 선택으로 길이 길이 남을 것이다. 다행히도 공백 문자를 “아주” 많이 써야 하는 경우는 포매팅되지 않은 텍스트 정도에 지나지 않고 그마저도 ~~~~를 사용한 delimited block으로 대체되는 추세이긴 하지만…
좋은 개발 모델이 부족하다. 크레올은 그래도 나름 기존의 위키 문법들을 분석하고 샘플 텍스트들의 분포도 분석하고 다른 위키 구현체들의 의견도 받아서 자기 딴에는 그럴듯한 문법을 만들어 냈다고 하고 있지만, 마크다운은 한 번 나온 뒤로 업데이트는 그냥 망해 버렸다. ~~그러니까 빨리 pandoc이 표준 마크다운 구현이 되어야 할텐데…~~
좋은 개발 모델의 부재로 인해 확장들이 다소 난립하는 경향이 있다. 다행히 마크다운 엑스트라는 다들 채용하고 있는 것 같지만 그 이상의 확장, 이를테면 github에서는 낱말 안의 밑줄을 문법으로 해석 안 한다거나… 하는 쓸만하긴 한데 구현체마다 제각기 다른 확장들은 답이 없다.
물론 마찬가지 이유로 좋은 테스트 슈트도 모자란다. (레딧에서 내 의견에 누군가가 답글을 달면서 언급했듯, 이 문제는 “마크다운은 파싱이 어렵다”라는 인식을 만들어 내는 데도 한 몫 했다. 사실 마크다운은 공백에 의존한다는 점만 주의한다면 파싱이 그다지 어렵지 않다.)

내가 위키 문법이 마크다운에 비해서 절대적으로 우위를 차지하고 있는 거의 유일한 분야라고 생각하는 건 단연 확장 부분이다. 당연한 얘기지만 자기가 마음대로 정할 수 있다면 확장도 수월할 수 밖에. 이걸 좀 더 깊게 생각하면, 많은 부분에서 확장에 필요한 것은 완전히 새로운 문법보다는 기존에 존재하는 문법에 추가적인 정보를 덧붙이는 것이고, 이 annotation 기능은 위키 문법이든 마크다운이든 그다지 썩 좋은 게 없다. (이 면에서는 reStructuredText가 굉장히 좋은 편이다. 단지 널리 안 쓰일 뿐.) 예를 들어서 위에 언급한 유튜브 동영상 보여 주는 것은 단순히 링크에 “이 링크는 유튜브 동영상을 가리킨다”는 annotation만 있어도 충분한 것이다. 마크다운을 가상으로 확장해서 예제를 써 본다면:

아라카와 언더 더 브릿지 오프닝 무시하나요!
[오프닝](http://youtube.com/watch/?v=gPXmvqZIn8Q @youtube)

뭐 이런 느낌. 실제 문법에 대한 딴지는 걸지 말자. (굳이 youtube가 아니라 video라는 이름을 써도 좋다.) 심지어 @youtube라는 annotation을 몰라도 이걸 HTML에서 class 정도로만 올려 주면 자바스크립트 단에서 파싱을 한다던지 뭘 한다던지 하는 대안을 써 볼 수도 있는 것이다. 이 정도의 annotation만으로 확장이 용이치 않은 경우가 있긴 한데 (이를테면 위키 링크의 경우 충분히 자체 문법이 필요할 정도로 많이 쓰이니까…) 많은 편은 아니고, 약간의 센스만 있어도 문제를 해결할 방법은 충분한 것이다. 단지 나서서 하는 사람이 없어서 못… 할 뿐이지.

이 문제를 내가 해결을 안 해 보려고 한 건 아니다. 실제로 나는 세 개 정도의 커스텀 마크업 문법(…)을 고안한 적이 있고, 그 중 하나는 PHP로 거의 완벽하게 구현해서 상용 소프트웨어에 디플로이될 뻔한 적도 있다.² 다른 하나는 reST로부터 아이디어를 얻어서 위에서 말한 문제를 해결하려고 노력해 보았으나 귀찮아서 구현을 못 했고 (이 때 참조한 마크업 문법만 열 개 가까이 되는 것 같다), 그 뒤로는 때려 치고 HTML을 직접 쓰는 무지막지한(하지만 의외로 그럴듯한) 일을 하곤 했었다. 그러던 내가 지금 마크다운을 쓰는 것은 마크다운이 이런 내 까다로운 성향에도 상당히 부합하기 때문이다. 물론 확장 부분은 굉장한 문제로 남아 있어서 결국 Mako랑 갖다 붙이는 미친 짓을 하긴 했지만… 어쨌든 내가 필요한 정도의 확장은 되니까 나는 문제 없다. 다만 이 해법이 나 같은 사람이나 쓸만한 방법이기 때문에 여전히 문제가 사라지는 건 아니니까, 내가 애정으로 이렇게 까는 거다. 흑흑.

크레올 쪽 통계를 인용하면 링크 주소가 앞에 오는 위키 문법이 뒤에 오는 문법보다 두 배 쯤 많긴 하지만 뒤에 오는 문법을 무시할 수는 없는 정도의 수효를 보이고 있다. 게다가 많은 위키들이 사용하는 [[xx|xx]] 같은 대칭적인 문법은 어느 쪽이 텍스트인지 알아 보기 쉽지 않게 한다. ↩
옛날 태터툴즈에 위키 비스무레한 문법을 넣으려는 시도… 혹시 기억하는 사람이 있나 모르겠다. 그 코드는 결국 위지윅 에디터 문제랑 맞물려 커밋하지 못 했다. ↩

비트버킷이냐 github냐

Tue, 06 Jul 2010 12:55:00 +0900

하루에 하나씩 긴 글을 쓰는 연습을 해야 겠다. 요즘 풉;만 너무 많이 쓰다 보니까 짧은 글에 익숙해진 것 같아서.

아는 사람은 아는 얘긴데 hg.mearie.org은 비트버킷과 상호 동기화가 되고 있다. (누군가가 이거 어떻게 했냐고 물어 보는데 사실 별 건 없고 crontab에다가 모든 저장소를 주기적으로 push/pull하도록 설정해 놓았을 뿐이다…) 근데 최근에 홍민희 님의 lisphp가 HN에 한 번 뜨더니 갑자기 github watch 수가 폭발적으로 증가하는 걸 보고 “아… 이거 github에도 가입해야 하는가” 하는 생각이 잠시 들었다. 비트버킷에 내 저장소가 서른 세 개(오늘자 기준) 씩이나 있는데 그 중 누군가 다른 사람이 follow하는 건 내 기억으로 두 세 개 밖에 없어서¹, 비트버킷이 절대적으로 사용자가 부족한 것 같다는 느낌이 드는 것이다. (물론 기업들에서는 비공개 저장소로 좀 많이 쓰는 것 같긴 하지만.)

앞에서 github에 가입을 하느니 마느니 하는 걸 보면 알 수 있겠지만 나는 github 계정이 아직 없다. 기본적으로 나는 git을 거의 쓰지 않기도 하고, github가 은근히 복잡하다는 느낌도 있어서 그랬던 것 같다. github이 분명 기능은 많지만 나처럼 최소주의적으로 사는 사람들한테는 쓸데 없이 복잡한 것 같다. 사실 나는 비트버킷에서도 기능 별로 안 쓰고 그냥 저장소만 사용하기 때문에… (물론 누군가 다른 사람이 기여를 하기 시작하면 그 때부터는 위키도 열고 이슈 트래커도 열어야 하겠지만 그럴 일이 지금껏 없었다 -_-) 그리고 비트버킷 말고 hg를 지원하면서 비트버킷 수준으로 자유로운 서비스도 별로 없기 때문이기도 하고. 이를테면 구글 코드도 hg를 지원하긴 하지만 내 기억으로는 계정당 저장소 수가 제한되어 있고 라이선스 제한이라던지 그런 것들도 귀찮단 말이다. 구글 코드가 먹고 들어 가는 점은 순전히 굉장히 깔끔하고 간단한 인터페이스 뿐인 것 같고, 나머지는 거의 구색 맞추기 같다 — 특히 개발자들 사이의 상호작용이 전혀 고려되어 있지 않다.

최근 비트버킷이 다국어 번역을 하고 있는 것 같은데 어쩌면 이게 비트버킷이 github보다 앞서 나가려고 준비를 하는 걸수도 있겠다 싶었다. 물론 이런 데에 계정을 만들 개발자들은 보통 최소한의 영어 실력이 있기 때문에 의미가 없을 수도 있겠지만, 그래도 자국어 사이트가 더 편안하고 영어 못 하는 개발자들도 쉽게 접근할 수 있다는, 즉 진입장벽을 낮추는 효과는 있다고 본다. 뭐 그래서 본 즉시 바로 가입하고 번역 시작해서 40% 정도 번역한 것 같은데… 관심 있으신 분은 번역 도와 주세요. 저도 안 써 본 기능 많아서 번역이 쉽지 않군요. ㅎㅎ;;;;; (이러고 있다.)

아마 esotope/migol, vlaah-python 정도 밖에 없지 않나 싶다. ↩

어제 오락실에 가서 유비트를 하려고 했는데 두번째 판에서 갑자기 카드가 인식되지 않는 것이었다. 첫번째 판에서는 아무 문제도 없이 잘 되었기 때문에 설마 카드 이상인가 싶었는데,...

Mon, 05 Jul 2010 02:02:59 +0900

어제 오락실에 가서 유비트를 하려고 했는데 두번째 판에서 갑자기 카드가 인식되지 않는 것이었다. 첫번째 판에서는 아무 문제도 없이 잘 되었기 때문에 설마 카드 이상인가 싶었는데, 다른 사람 카드는 잘 되어서 “아 드디어 이 카드가 망했구나”라는 것을 직감했다. 자석에 갖다 문지른 것도 아니고 고작 1년 조금 넘게 지난 카드인데 벌써 죽나 싶긴 한데 하여튼 카드는 망했으니 다시 사야 할 일. 근데 오락실에서 돈 없다고 카드를 안 들여 놓아서¹ 결국 다른 오락실 가서 카드를 새로 산 뒤, 근처에서 잡히던 무선랜으로 이어뮤즈먼트 사이트로 바로 접속해서 카드 이전하니 잘 된다. 근데 암호(저 동네에서는 PIN 코드인가라고 부르던 것) 바꿀 수 있는줄 알았는데 안 되더라…

옛날 카드에는 분실 대비용으로 메일 주소를 써 놓았었는데, 그 메일 주소랑 현재 플레이어 이름이 내가 공개용으로 쓰지 않는 별도의 닉에 관련된 것인지라 (아는 사람은 아는 그…) 일단은 새 카드에 아무 것도 안 써 놓은 상태이다. 그래서 유비트 새 버전이 나오면 공개해도 아무 상관 없는 새 플레이어 이름을 쓸 작정인데 그 때 새로 메일 주소를 써 놓을 생각이다. 근데… 니트는 언제 나오지?

듣기로는 코나미·유니아나 측에서 50개 묶음으로 사야 한다고 강제를 한다고 한다. 근데 50개 산다고 그게 언제 팔릴지는 모를 노릇이니 오락실 입장에서는 굉장히 난감할 수 밖에. ↩

Five Years of Some IRC Channel

Fri, 02 Jul 2010 03:24:00 +0900

As some of you know I used to run my own IRC channel since 2004 (well, not strictly “my own”, but formally I assumed that role) and kept a log of the channel since September 2005. After I see Dominic Szablewski’s excellent visualization of 9 Years of Sleep, I decided to make my own picture.

Compared to Szablewski’s one, my log is comprehensive as I use an irssi proxy to keep my connection and it results in the following dense picture: (Click to enlarge.)

While the pattern inside it is not so obvious at the first glance, you can see a repetitive pattern of seven-day cycle after some inspection. Moreover it shows a great shift of active time zone in early 2007: persons didn’t start to talk before 12 PM in 2005, but they started to talk at 9 AM in 2007. It can be explained by the fact that key people in the channel became the university student at that year. Also note that the density of the chat log peaked around early 2008 — that is also a moment that the number of users peaked at 60+ persons. (That have been reduced to 40+ persons now.)

I have a bunch of ideas that can be made from my collection of chat logs. For example, the separate picture can be made from logs of each persons or keywords. (The former is not that simple since many persons tend to use two or much more nicks; someone even managed to use estimated 400+ nicks for years.) Or we can make a graph between users calling them. I even generated a random chat log from the historic logs and made fun of it. That’d be just a matter of time.

요전에 발로 하는 파이썬 세미나 얘기를 한 적이 있었는데 슬라이드를 메아리에 공식으로 올렸다. 이미 보신 분은 상관 없겠지만 그래도 홍보차(?)… 쓸데 없는 얘기긴...

Wed, 30 Jun 2010 23:53:00 +0900

요전에 발로 하는 파이썬 세미나 얘기를 한 적이 있었는데 슬라이드를 메아리에 공식으로 올렸다. 이미 보신 분은 상관 없겠지만 그래도 홍보차(?)…

쓸데 없는 얘기긴 하지만 URL로 쓸 영문 제목을 뽑느라 잠시 고민을 했는데… 결과적으로 정한 제목은 “How (not) to teach Python”이었다. 에반게리온 신극장판의 영문 제목들이 모조리 저런 식으로 되어 있는게 생각나서 그냥 그렇게 정했다. 근데 나는 에반게리온을 한 번도 본 적이 없단 말이지. 흠.

월드컵이 뭔가요? 먹는 건가요? 우걱우걱

Sun, 27 Jun 2010 20:13:00 +0900

한국의 8강 진출 실패가 결정된 오늘 밤 1시 쯤에 매점에 들렀다가 매점 아줌마가 희한하다는 표정으로 쳐다 보시더라. 그러더니 하시는 말씀:

“학생 뭐 좋은 일 있어?”
“아뇨 뭐 별건 아니고… 먹을 거 사러 왔으니까.”
“남들은 축구 져서 울상인데 학생은 싱글벙글이네? (웃음)”
“뭐 저는 축구 안 보니까요. (웃음)”

개인적으로는 한국이 16강에 져서 단독 중계권을 먹은 SBS가 좀 엿을 먹었으면 좋겠다고 생각했는데 — SBS야 물론 리스크를 감수하고 중계권을 먹은 거겠지만, 리스크가 항상 기회라고 착각하지는 않았으면 좋겠다는 생각에 — 그건 안 되어서 아깝고, 축구야 내 관심사 바깥이니 신경은 쓰지 않는다. 그냥 남들이랑 얘기할 때 최소한의 상식 정도로 알기 위해서 결과만 알아 두는 정도.

월드컵에 관심이 없는 이유는 또 하나 있다. 월드컵은 “세계인들의 축제”라는 명분 하에 자본주의와 국제화의 나쁜 점만 강화시키는 효과가 있고, 그걸 관장하는 국제축구연맹(FIFA)은 그걸 틈타서 세계적인 월권행위를 저지르며 돈을 긁어 모으고 있다. 이게 가능한 이유는 국제축구연맹이 국제연합(UN)보다도 더 많은 회원국을 갖고 있는, 월드컵이라는 막강한 컨텐츠를 담보로 한 강력한 단체이기 때문이다. 자세한 얘기는 내가 쓰는 것보다는 주간조선의 글을 읽어 보는 게 좋겠고, 하여튼 그러하니 나라도 신경을 끄는 것이 이 세상을 위해서 더 나을 것 같아서 이러고 있다. 축구를 못 하느니 뭐가 재밌는지 모르겠다느니 하는 건 차라리 부차적인 이유이다. (왜냐하면 나는 축구는 안 보지만 마라톤은 보기 때문에… 안 움직이는 한 뭐라도 상관 없긴 하다.)

뭐… 이렇게 생각하는 사람은 나 밖에 없으려나.

도쿄도 다이토구에 야나카하츠네쵸라는 지명이 있어서 행정구역이 통합1된 지금까지도 그 흔적이 남아 있다고 한다....

Thu, 24 Jun 2010 04:15:00 +0900

도쿄도 다이토구에 야나카하츠네쵸라는 지명이 있어서 행정구역이 통합¹된 지금까지도 그 흔적이 남아 있다고 한다. (찾아 보니까 도쿄도 말고 후쿠오카현에도 하츠네쵸라는 지명이 있는 것 같은데 잘 모르겠다.) 업로드 코멘트에 “지역 모에는 주민의 폐가 되지 않도록 합시다”라고 쓰여진 게 압박… 원곡은 capsule의 Hello. 아 capsule 요즘 안 들으니까 신곡도 모르겠다.

1966년 이후 야나카 1~7쵸메로 재정비되었다. 일본어 위키백과 참고. ↩

요즘은 풉;을 지나치게 많이 쓰고 있어서 그런지 DokuWiki-custom 업데이트가 굉장히 잦다. 허허허. 풉;도 좀 들러 주세요. 하는 김에 마지막으로 업데이트된 지 몇 달...

Wed, 23 Jun 2010 02:52:24 +0900

요즘은 풉;을 지나치게 많이 쓰고 있어서 그런지 DokuWiki-custom 업데이트가 굉장히 잦다. 허허허. 풉;도 좀 들러 주세요. 하는 김에 마지막으로 업데이트된 지 몇 달 지난 비트버킷쪽 위키 문서도 좀 고쳤다.

문서에 추가한 내용 중 DWc에 대한 내 철학을 보여 주는 문구:

There is no tagged release of DokuWiki-custom: every revision is considered stable. If you prefer some kind of version number, the current (tip) version is dated 2010-06-22.

사실 stable하지 않으면 당장 나부터 문제가 생길 것이기 때문에 stable하게 하려는 게 당연한 것이긴 하다. (…) point release도 귀찮기도 하고… 물론 이 철학의 문제점은 사용자가 업데이트하기 좀 귀찮다는 건데, 뭐 매 리비전이 stable하면 업데이트 안 해도 대강 대충 쓰는 데는 문제가 보통 없을테니 그러려니 하고 있다. 게다가 지금 당장 DWc의 주 사용층은 내 주변인들로 한정되어 있으므로 사실 이 걱정을 할 필요도 없긴 하지만.

서버 운영에는 보통 수많은 변수가 작용한다. 서버에 입주한 사이트들, 해당 사이트 관리자의 성실성(특히 얼마나 소프트웨어 업데이트를 잘 하느냐), 사이트의 특성, 사이트의 평균...

Tue, 22 Jun 2010 00:45:00 +0900

서버 운영에는 보통 수많은 변수가 작용한다. 서버에 입주한 사이트들, 해당 사이트 관리자의 성실성(특히 얼마나 소프트웨어 업데이트를 잘 하느냐), 사이트의 특성, 사이트의 평균 트래픽과 최고 순간 트래픽(보통 10배 쯤은 차이 난다), 그 밖에 서버에서 돌아 가는 서비스의 목록… 등등. 하지만 어제 23시 40분에서 오늘 0시 10분까지 서버가 개판이었던 건 아무도 생각도 못 했던 복병이었다.

나한테는 페레멘이라는 애증의 관계에 있는 후배가 하나 있는데, 이 놈 방에 다른 후배와 같이 좀 놀러 갔다가 푸규루를 본 뒤 다들 심심해서 놀던 중 이 녀석이 갑자기 덮밥을 하는 바람에 복수를 계획한 끝에 이 놈이 방에서 나오려는 순간 얼굴에 물을 뿌리는 데 성공했다. (음… 솔직히 서로 어지간히도 심심해서 이런 짓을 하고 있었던 거라고 생각한다. 보통은 바쁘니 이럴 시간은 없다.)

그러고 나서 유유히 팥빙수를 사가지고 내 방으로 돌아 왔는데 서버가 거의 죽어 있는 것이었다! (ssh 및 IRC 서버만 빼고 모든 데몬이 죽어 있었다.) 너무 황당해서 이 녀석한테 전화를 해서 좀 추궁을 했더니… 곧 Magic SysRq 키를 눌렀다고 실토를 한다. 으악.¹ 너무 데몬이 많이 죽은 덕택에 오랜만에 내 자의로 서버를 재부팅해야 했다. O<-< 아니 아무리 물 좀 먹었다 그래도 서버를 날리다니… ~~차라리 내 방에 와서 물을 뿌릴 것이지~~이렇게 썼다가는 정말로 물 뿌리러 올 것 갈아서 취소. 하여튼 오늘의 교훈은 서버 관리라는 건 정말 어렵다는 거…

ssh 접속만 가능한 서버이므로, 정황상 echo e > /proc/sysrq-trigger를 했으리라 추측된다. 즉 모든 프로세스에 SIGTERM을 날려 버린 것. -_-; 참고로 이 녀석도 비상시에는 서버 관리 권한이 있다. ↩