Lbird's Computing

EUC-KR이 UTF-8로 저장돼서 깨진 한글 일부 복구하기

Lbird — Tue, 8 Mar 2016 16:07:35 +0900

벌써 두번이나 했는데 매번 기억이 안 나서 몇번씩 시행착오를 한 관계로 잊어버리지 않기 위해서 기록한다.

Source code에 한글로 comment를 쓰기 좋아하는 사람들(사실 나도 간혹 그런다)이 꽤 많이 있는데, file의 character encoding만 잘 맞춘다면야 comment를 뭘로 쓰든 사실 별 상관이 없다. 오히려 자신의 제일 잘 구사할 수 있는 언어인 한국어로 설명을 달아놓는 것이 더 좋을 수도 있을 것이다. 그런데, 이건 encoding을 잘 맞출 때나 할 수 있는 얘기고, EUC-KR이나 CP949로 저장되어야 할 파일을 어찌어찌 하다가 UTF-8 같은 것으로 저장해버리는 일이 종종 생긴다. 흔히 editor가 EUC-KR로 encoding된 파일을 열 때 제대로 decoding을 하지 않은 채로 열고, 저장할 때는 그냥 UTF-8로 저장해 버리는 경우에 많이 발생하는 듯 하다. 어쨌거나 내가 최근 며칠 사이에 아주 자주 마주치는 상황은 아마도 그런 전차로 발생한 듯 한다.

어떻게 이런 일이 일어났는지는 뭐 알 수 없는 거고, 현재 상태만 설명하자면 이렇다.

파일의 실제 character set은 EUC-KR이다.
그런데 이 파일이 적절한 decoding과 다시 적절한 encoding 없이 바로 UTF-8로 저장되었다.

이것을 다음과 같은 과정을 거쳐서 복원 시도할 것이다.

UTF-8을 decoding해서 latin1으로 표현된 파일을 얻는다.
이 파일을 EUC-KR로 decoding한 후에 다시 UTF-8로 encoding한 파일을 얻는다.

2번의 결과물을 보면 망가졌던 한글 character 중 대략 70% 정도는 복구할 수가 있다. 그리고 나머지는 사람의 두뇌를 이용해서 복구가 안된 글자들을 상상해서 끼워 맞추는 작업이 필요하다.

최초의 파일(file1.c)은 이렇다. (vim에서 열어 본 것. ~/.vimrc에서 fileencodings는 ucs-bom,utf-8,euc-kr,cp949,iso-2022-kr,latin1 로 설정되어 있음)

이것을 bvi로 열어서 해당하는 부분을 보면 아래와 같다.

첫번째 변환은 다음과 같이 한다.

iconv -f utf-8 -t latin1//IGNORE file1.c > file2.c

최초 파일(file1.c)을 utf-8로 인식하여 연 다음에 latin1으로 변환하라는 뜻인데, latin1은 사실 아무런 변환을 하지 않은 것과 같다. 따라서 우연히 utf-8로 잘못 저장된 내용을 복구한 것이 된다.

이 결과는 다음과 같다(file2.c)

vim에서는 같은 것처럼 보이지만, 처음은 encoding이 utf-8이었고, 지금은 latin1으로 인식한다.

bvi로 열면 다음과 같다. 분명 파일 내용은 바뀌어 있다.

여기에서 생각할 것은 이 파일은 encoding은 실제로는 euc-kr이라는 것이다. 적절한 code 변환 없이 저장되는 바람에 일부 byte들이 유실되었고 vim로 자동인식해서 열어봐도 그냥 latin1으로 표시될 뿐이다. 이 파일을 강제로 euc-kr로 인식시키고자 다시 iconv를 이용한다. 두번째 변환은 다음과 같다.

iconv -f euc-kr -t utf-8//IGNORE file2.c > file3.c

이 결과물(file3.c)은 제대로 utf-8로 저장된 파일이 된다.

vim에서 열면 아래와 같다.

bvi로 열면 아래와 같다.

마지막 결과를 잘 보면 한글 한 글자당 3 byte가 사용되는 제대로 된 utf-8 encoding인 것처럼 보인다. 물론 몇가지 글자들은 정보 유실 때문에 여전히 깨지기도 하고, 복원하는 과정에서 잉여 byte들이 끼어들어 뭔가 더 길어진 것처럼 보이기도 한다. 잘 인지되지 않는 글자들은 무시한다. 시간이 남는다면 유실되거나 추가된 byte들을 이러저리 만져보면서 완전한 원본을 만들어낼 수도 있겠으나, 나는 지금 이 글을 쓰면서도 이미 시간을 많이 소비했다. ㅋㅋ 나머지는 나의 한국어 실력을 믿기로 한다.

보안의 보짜 (패스워드편)

Lbird — Tue, 1 Dec 2009 10:57:48 +0900

Draco님의 tweet에서 보고는 구글링해서 들어가 본 Unu라는 사람의 블로그에서 씁쓸한 글 하나를 읽었다. 요약하자면, 루마니아에 사는 자칭 화이트 해커(ㅋㅋ)라는 Unu라는 사람이 nProtect 홈페이지를 해킹해서 사용자 정보를 볼 수 있었다고 광고한 일이다. 국내 뉴스에서는 화이트해커라고 하던데, 뭐, 말하자면 공격해서 취약점은 밝혀서 망신을 주지만, 빼낸 정보를 악용하지는 않는다는 뭐 그런 얘기다. 그렇다고 하니 믿을 수밖에. :) Unu라는 사람은 SQL injection을 이용해서 홈페이지를 뚫긴 했는데, 나의 눈을 이끈 부분은 그런 자세한 해킹 기법이 아니고, nprotect에서 사용자의 패스워드를 clear text로 보관하고 있었다는 사실이다. 웃기는 짬뽕이다. 서버 해킹 당한 거는 이러저러한 연유로 그렇게 될 수도 있다 치지만, 사용자 패스워드를 clear text로 보관한다는 건, 사이트의 설계 당시부터 애초에 잘못된 보안 개념을 가지고 있었으며, 아직까지도 고칠 여유가 없었거나, 고칠 능력이 없었거나, 아니면 그게 잘못된 것인지를 아예 모르고 있었다는 얘기다.

이게 왜 잘못된 거냐 하면... 코딩이 짜증나니 머리도 식힐 겸 친절한 썰을 하나 풀도록 하자.

아이디와 패스워드는 대표적인 개인 인증 방식에 사용된다. 아이디는 자신의 이름과 같은 것이어서 각각의 개인을 구분하는 정보이고, 패스워드는 그 개인만이 알고 있는 비밀 정보이다. 패스워드를 알고 있는지 여부를 살펴서 그 아이디의 주인이 맞는지를 확인한다. 이게 대충 수박 겉핥기 식으로 정의하는 인증이다.

사실 이것보다는 우리가 허고헌날 쓰는 자물쇠와 열쇠의 비유를 쓰는 것이 좋겠다. 우리가 자물쇠를 열쇠로 열 때, 그 자물쇠에 꼭 맞는 열쇠가 있어야만 한다. 다른 말로 하자면, 자물쇠는 자신과 꼭 맞는 열쇠만을 인식한다. 자물쇠를 아무나 열지 못하게 하려면, 우리는 열쇠를 잘 간수해야 한다. (사실 우리는 열쇠를 꽁꽁 숨겨 다니지도 않고, 누가 열쇠를 쳐다 본다고 해서 그 열쇠를 도둑맞았다고 호들갑을 떨지는 않는다. 그래도 사진기와 같은 아주 정확한 기억력을 가진 누군가가 열쇠를 쳐다보고, 머리 속에 사진을 찍어 두었다가 그것과 똑같은 열쇠를 만든다면 열쇠를 도둑 맞은 것과 똑같은 상황이 되긴 한다. 물론, 보통 사람들은 그런 기억력을 가지고 있지 않기 때문에 우리는 열쇠를 누가 쳐다보는 것에 둔감하고, 그럴 만도 하다.) 열쇠의 모양은 자물쇠와 열쇠 사이의 비밀정보이다. 문지기가 자물쇠 옆에 늘상 붙어 있다고 해도, 자물쇠만 봐서는 열쇠의 모양을 알 수가 없다. 첩보 영화에 나오듯이 밀랍 덩어리를 자물쇠 안에 넣어서 모양을 짜내지 않는다면 ;)

그림으로 그리자면 이런 식이다.

발로 그린 그림이지만, 왼쪽이 자물쇠 오른쪽이 열쇠라고 너그럽게 봐 주도록 한다. (열쇠가 더 커 보이는 건 착시현상이다. 어찌됐든, 열쇠를 자물쇠에 넣는 것이 더 큰일 같아 보이긴 하다. ^^ ) 문지기는 사용자가 열쇠를 자물쇠에 넣는 짧은 동안에는 열쇠를 슬쩍 관찰할 수 있다. 문지기의 눈이 고감도 카메라라면 이 순간 열쇠는 도둑맞은 것이나 다름 없지만, 우리는 문지기의 관찰력이 그리 높지 않다고 대충 가정한다. 이러한 방식과 유사한 것이 대부분의 ID/PW 방식의 인증들이다. 사이트는 사용자가 전송한 패스워드를 짧은 기간동안 clear text로 볼 수 있다. 사이트 관리자가 딴 생각을 품고 이 패스워드를 다른 곳에 기록해 놓는다면 (문지기의 카메라 같은 시각) 이 사용자의 패스워드는 그 관리자에게 노출된다. 그런데, 암묵적으로 우리는 관리자가 인증 과정에서 관찰한 패스워드를 따로 몰래 저장해 놓지는 않는다고 가정한다.

앞의 nprotect 같이 패스워드를 평문으로 저장하는 것은 아래 그림과 같이 표현할 수 있다.

이게 뭔가. 열쇠를 관찰하는 사람 말고도 자물쇠를 관찰하는 사람도 열쇠의 모양을 알 수 있다. 이 경우에는 문지기의 눈을 가려 놓거나, 자물쇠를 또 다른 것으로 감싸고 거기에 또 다른 자물쇠를 달거나 하지 않으면 열쇠를 만들 능력이 되는 모든 사람이 자물쇠를 열 수 있다. 이런 바보 같은 자물쇠를 만드는 사람은 없을 것이다.

통상적인 Unix 패스워드 시스템에서는 자물쇠를 일방향 함수로 만든다. 일방향 함수라는 것은 순방향으로는 계산이 쉽지만, 역방향으로는 계산이 어려운 함수이다. 일방향 함수가 아닌 함수의 예는 쉽게 이런 것을 들 수 있을 것이다. f(x) = x + a. -.-;; f(x) = y 일 때, y를 알면 x는 당장 알 수 있다. x = y - a의 관계가 있기 때문이다. (물론 함수 자체는 완전히 주어진다. 즉, a가 공개된다.) 그런데 일방향 함수는 f(x)가 완전히 주어져 있을 때에도 역방향 계산이 어려운 함수이다. 사용자의 패스워드는 x(열쇠)에 대응되고, 서버가 보관하고 있는 것은 패스워드의 일방향 함수값 y(자물쇠)에 대응된다. 열쇠(x)가 들어오면, 서버는 일방향 함수를 통과시켜서 일방향 함수값(y)을 구하고 저장하고 있는 일방향 함수값과 같은지 비교한다. 같으면 통과, 틀리면 실패이다. 보통 자물쇠와 같이 서버는 저장하고 있는 일방향 함수값(y, 즉 자물쇠)만 가지고는 패스워드(x, 즉 열쇠)를 알 수 없고, 사용자가 패스워드를 주었을 때 맞춰 볼 수만 있다. (물론, 이 때 서버는 사용자가 전달한 패스워드를 인증이 끝나면 폐기한다는 조건이 있어야 한다.)

또다른 잡담으로, 앞의 보통 자물쇠의 경우 기술이 좋아서 자물쇠 내부를 잘 들여다 볼 수 있는 사람들이 있다. 시중에 떠도는 금고털이들이 그렇다. 그건 자물쇠의 구조적인 한계 때문이기도 하고, 그림처럼 열쇠의 모양을 마음대로 만드는 것이 아니라 생각해 볼 수 있는 열쇠의 모양의 가지수에 한계가 있기 때문이기도 하다. 이 경우, 문지기는 이런 공격을 시도할 수 있다. 열쇠 하나를 만든다. 자물쇠에 맞춰본다. 안 맞으면 다른 열쇠를 만든다. 또 맞춰본다. 이런 걸 몇백만번쯤 하면 자물쇠에 맞는 열쇠를 만들 수 있을 것이다. 더구나, 열쇠/자물쇠의 규격이 문제가 있어서, 열쇠의 모양에 한계가 있다면 만들어야 하는 열쇠의 수는 줄어든다. 톱니가 4개 달린 열쇠에 톱니 하나당 높이의 단계가 10개 뿐이라면, 열쇠를 만개만 만들어보면 된다. 실제 ID/PW 인증의 경우에는 열쇠를 만드는 게 정말 아무것도 아니다. 만개의 열쇠를 만들어서 자물쇠와 맞춰보는 작업을 몇초~몇시간 안에 할 수 있다. 그러니, 패스워드를 그냥 숫자 키패드에서 몇개 찍어서 쓰는 사람들은 몇초 안에 깨질 수 있는 패스워드를 쓰고 있다는 뜻이 된다.

또또 다른 잡담으로, 인증 과정에서 열쇠를 슬쩍 훔쳐볼 수 있는 서버(또는 문지기)가 탐탁치 않을 경우에는 어떻게 하는가. 자물쇠와 열쇠의 예에서는 비교적 간단하다. 열쇠를 조심해서 꺼내고, 손으로 잘 감싼 후에 자물쇠와 열쇠를 잘 갈무리해서 열면 된다. 열고 나서도 손으로 잘 감싸서 주머니에 넣으면 된다. 그럼 ID/PW를 이용한 인증에서는? 사실 방법이 없다. 자물쇠와 문지기의 예에서는 자물쇠와 문지기가 별개의 객체인 것처럼 말을 했지만, 실제로는 그렇지가 않다. 굳이 비유하자면, 사용자가 열쇠를 문지기에게 주면, 실제 열쇠를 자물쇠에 맞춰보는 건 문지기가 한다. 문지기에게 줄 때까지 열쇠를 아무리 잘 갈무리해봤자 일단 문지기에게 주고 나면 문지기가 열쇠를 빼돌리지 않는다고 그냥 믿어야 한다.

이와 관련하여, 웹서버의 경우 https 통신을 하면 무조건 안전하다고 믿는 사람들이 있다. 뭐, 사실 안전도가 비약적으로 상승하는 것은 맞다. 앞의 비유에서는 사용자가 문지기의 바로 앞에서 열쇠를 꺼내 주는 것처럼 보이지만 그렇지가 않기 때문이다. 현실에서는 열쇠를 꺼내서 본을 뜨고 어쩌고 해서 열쇠의 (완전히 똑같은) 사본을 만든다. 그리고 속이 잘 비치는 편지 봉투에 넣고 우편함에 넣으면, 오토바이를 타고, 트럭을 타고, 기차나 비행기를 타고 문지기에게까지 배달된다. 그리고 문지기가 열쇠를 자물쇠에 맞춰본다. 그러니 배달 과정에 있는 수많은 사람들이나 또는 우편함 속에 몰래 숨어 있던 스파이가 열쇠를 빼돌릴 수 있다. https 통신을 하면 열쇠를 무지하게 튼튼한 봉투에 넣어서 전달하는 것과 같게 된다. 그러니, 걱정해야 하는 수많은 사람들은 나가 떨어지고 문지기만 남게 된다. 안전도는 비약적으로 상승한다. 하지만... 여전히 문지기는 남아 있다. ID/PW 방식을 사용하면 이건 어찌해 볼 수가 없는 문제이다. PKI 방식을 쓰는 수 밖에.

ps. 그림 그리는 게 제일 힘들었음. -.-;;
ps2. 왜 글이 점점 늘어나지 -.-;; 일하기 싫다는 증거.
ps3. 패스워드편 말고 다른 게 있을지는 며느리도 모름.

Quodlibet에서 Winamp로

Lbird — Sat, 14 Nov 2009 17:48:25 +0900

분신처럼 들고 다니던 노트북의 액정이 맛이 가는 바람에 더 이상 이 분신을 들고 다닐 수가 없다. 그래서 방에다 LCD 하나 연결해 놓고 거의 데스크탑처럼 써 먹고 있는데, 그러다 보니 하루 중 제일 많이 접하는 컴퓨터가 노트북에서 랩에 있는 데스크탑으로 변했다. 거진 1년만인 것 같네.

문제는 노트북에 있던 음악 파일들을 모두 데스크탑으로 옮기고 난 후에 생겼다. 노트북에 있던 우분투에서는 quodlibet이라는 프로그램으로 음악 정리하고 듣고 그랬는데, 이 quodlibet에서 설정한 album artist 태그가 데스크탑에 깔린 winamp에서는 먹질 않는 거다. 좀 찾아봤더니, quodlibet에서는 quodlibet::albumartist 라는 custom tag에 album artist를 기록하는데, winamp에서는 tpe2라는 태그에 기록한다. 이 태그는 프로그램에 따라서 band라고 해석하도 하고, performer(quodlibet이 그렇다)라고 하기도 하고 album artist, 또는 orchestra라고 부르기도 하는 태그다. (관련글)

어쨌거나, 몇 천개 되는 mp3 파일에서 quodlibet에서 지정한 album artist를 winamp에서 알아먹을 수 있는 tpe2 태그로 옮겨 줘야 한다. mp3파일이 텍스트 파일이었으면 간단히 끝났을 텐데, 나는 요 mp3라는 녀석의 내부 구조에 대해서 아는 것이 없다. 그래서 적당한 프로그램을 찾아보았다. 그리고 찾았다. mp3tag 라는 프로그램이 있는데, 훌륭한 프로그램이다. 사용한 기능은, 다른 태그를 보고서 새로운 태그를 생성해 내는 기능이다.

아래 화면은 quodlibet에서 지정한 quodlibet::albumartist라는 custom tag를 리스트에 표시하도록 한 화면이다. 지금은 quodlibet::albumartist는 지정돼 있지만, winamp에서 album artist로 인식하는 tpe2태그(mp3tag에서는 %band%임)는 없는 상태이다.

작업할 파일들을 선택한 후, 메뉴에서 변환>실행을 누르거나 ALT+5를 누른다. 실행 그룹이라는 것이 뜨는데, 여기에는 각종 작업들을 하나로 묶은 "실행 그룹"이라는 것들이 나열된다. quodlibet의 albumartist를 winamp albumartist로 바꾸는 작업을 하는 것이니 "quodlibet albumartist to winamp albumartist"라는 이름의 실행 그룹을 새로 생성한다. 그리고, 실행 내용에는 소스형식을 %quodlibet::albumartist%로 정하고, 추측 방식을 %band%로 정한다. 이건, quodlibet::albumartist라는 이름의 custom tag를 읽어서 이 값을 band라는 태그(tpe2이다)라고 추측하도록 하자는 것이다.

그리고 나서는 실행 그룹 화면으로 돌아가서 방금 생성한 그룹을 체크하고 확인을 눌러주면 된다.

KCDSA & EC-KCDSA + OpenSSL

Lbird — Wed, 30 Sep 2009 16:46:00 +0900

국내에서 개발되어 국제표준인 ISO/IEC 14888-3 에도 들어가 있는 두 개의 전자서명 알고리즘이다. 이걸 OpenSSL에 어울리도록 코딩한 것이다.

올 봄에 나의 지도교수님의 언질로 만들었던 것인데, 애초의 마음먹은 것과는 달리 뒤에 가니 OpenSSL에 제대로 어울리는 코드는 만들어내지 못한 것 같다. 결정적으로 국내 표준에 명시된 HAS-160을 만들어 넣지 않아서 모양새가 좀 이상하다. 국제 표준(ISO/IEC 14888-3)에 있는 numerical example은 HAS-160을 안 썼다고 하기도 그렇고, 썼다고 하기도 그런 애매한 상태다. 국내 표준에 있는 numerical example과 맞아떨어지는 것을 제대로 구현하려면 HAS-160은 필수. 뭐, 그래서 OpenSSL에 패치를 보내는 거는 지금 상태에서는 적절하지 않고, 시간이 나면 HAS-160 코드를 만들어 넣으려고 했던 것도 시간이 지나니까 귀찮아져서 코드와는 점점 소원해진다.

그랴서... 그냥 썩혀 두기는 아깝고, 제대로 만들어 보자니 귀찮은... 계륵(?)과 비슷한 것이려나. 뭐, 어쨌든 여기에라도 포스팅해서 미끼를 던지고, 관심 두는 사람이 있는지 낚시질이나 해봐야겠다.

원래 올라가 있던 페이지: http://islab.postech.ac.kr/kcdsa.html

라이센스는 GPL v3

작성자는 Yeon-Hyeong Yang <yhyang@oberon.postech.ac.kr> <lbird94@gmail.com>

소스 코드:

invalid-file

USB 마우스 종종 먹통되는 문제

Lbird — Mon, 22 Jun 2009 19:12:36 +0900

아래의 어느 것도 문제의 원인이 아니었음! 단지 마우스가 불량이었음! -.-;; 아래는 그냥 기록상 남겨둠.

얼마전부터 노트북 배터리를 아끼려고 laptop-mode를 사용하고 있다. 그다지 큰 문제는 없었는데 어제였나 그저께였나부터 usb 마우스가 자주 깜빡 깜빡 동작을 멈춘다. 아예 먹통이 되는 것은 아니고 몇초간 멈춰있다가 다시 동작한다. 이런 현상이 대충 1분에 2-3번 발생한다. 짜증나 미칠 정도였는데 문제가 laptop-mode에서 설정해 놓은 usb suspend 기능 때문이었다. 일단 지금은 /etc/laptop-mode/conf.d/usb-autosuspend.conf 파일에서 CONTROL_USB_AUTOSUSPEND를 0으로 설정해 놓았다. 아마도 usb 장치를 일정 시간이 지나면 suspend해 버리고 마우스 동작이 있으면 다시 살아나서 수십초간 동작하다가 다시 suspend되고 하는 것이 바복되었던 모양이다. 그런데 의문인 것은 그동안은 괜찮다가 갑자기 엊그제부터 이런 현상이 생긴다는 것이다. usb 마우스가 사용중이라는 것을 어디에 있는 어느 녀석인가가 인식하지 못하고 autosuspend시켜 버리는 것 같은데 찾질 못하겠다. 어쨌든 우분투 9.04에 대대적인 update가 이루어지는 시기까지는 usb autosuspend 기능은 꺼 놓고 있어야 할 것 같다.

덧: 지금 보니 컴퓨터를 켜 놓은지 시간이 좀 지나면 다시 중간 중간 멈추는 현상이 생긴다. 그러다가 좀 더 있으면 마우스를 거의 사용할 수 없을 정도가 되다가 완전히 먹통이 된다. 이 상황에서도 터치패드는 잘 동작한다. -.-;; 이 상태에서 마우스를 뽑았다가 다시 꽂으면 한동안은 잘 동작한다. laptop-mode 자체에 문제가 있는 것인지도 모르겠다.

다시 덧: laptop-mode를 아예 끄고 지금까지 관찰해 본 결과, 이 마우스 문제는 laptop-mode와 관련이 없는 것 같다. 커널을 2.6.28-13을 사용하고 있었는데, 몇시간 전부터 2.6.28-11로 부팅해서 관찰해 보니 마우스 문제가 없다. 커널 문제란 말인가.

또 덧: 아침부터 2.6.28-12로 부팅해서 지금까지 마우스 문제가 없다. laptop-mode는 꺼진 상태다.

또 덧: 2.6.28-12로 처음 부팅할 때 init ramfs가 제대로 만들어지지 않은 것을 발견하고 부팅하기 전에 dpkg-reconfigure 로 2.6.28-12를 재설정했었다. 그래서 혹시나 하는 마음에 2.6.28-13도 reconfigure를 하고 지금 부팅해 봤는데 이런... 이거 커널에 문제가 있었다기보다 configure가 제대로 되지 않아서 문제였던 것 같다. 2.6.28-13으로 부팅후 30분 가량 지났을 때까지 마우스 문제가 없다. 아직 laptop-mode는 켜지 않은 상태이다.

몇 시간이 지나고 나니 또 살짝 살짝 마우스가 끊긴다. 특히 I/O를 기다려야 하는 작업이 많을 때 더 그런다. 아무래도 -13 커널이 이상하긴 이상한 것 같다.

아마도 마지막 덧: 아무래도 문제를 찾은 것 같다. 예전에 intel graphic card의 성능을 높이느라고 ubuntu forum의 글을 따라한 적이 있었는데 그 중에 X 서버의 최신 업데이트를 사용하는 것도 있었다. 마우스도 결국은 X가 떠 있는 상태에서나 의미가 있는 물건인지라 혹시나 하는 마음으로 최신 업데이트를 날리고 다운그레이드했다. 이제 2.6.28-13 커널을 사용하고 있어도 문제가 생기지 않고 있다. 얼마간 더 지켜 보면 이게 문제였는지를 확실히 알 수 있을 듯 하다.

Filezilla server의 아이콘 색깔

Lbird — Thu, 11 Jun 2009 16:43:59 +0900

그동안 신경을 쓰지 않고 있어서 모르고 있다가 방금 알았는데, Filezilla server interface 프로그램의 시스템 트레이 아이콘 색이 접속자가 있는지 없는지에 따라 색깔이 변한다.

client 접속이 없을 때 노란색

client 접속이 있을 때 녹색

banshee 1.5.0 released

Lbird — Wed, 3 Jun 2009 13:35:13 +0900

linux의 gnome 환경에서 쓸만한 음악 연주기 중에서 그 중 제일 쓸만하다고 판단되는 banshee 1.5.0이 나왔다. 근데 보면 aka 1.6 beta 1이라고 나온다. 안정버젼이 되려면 1.6이 될 때까지 기다려야 하는 건가? 어쨌든 현재 ubuntu jaunty 저장소에는 올라오지 않고 있는데 일단 subversion으로 받은 소스로 deb 패키지를 만들어서 설치했다. revision number는 5209라서 r5209 딱지를 붙였다.

invalid-file

monodoc-banshee-manual은 설치하지 않았는데 혹시나 해서(그냥 심심해서) 올려 둠.

근데 1.4.x 때보다 느려진 것 같다. 음악이 끊기거나 하는 건 아닌데 화면이 반응하는 속도가 참 아쉽다.

gvim에서 man page 제대로 보기

Lbird — Mon, 18 May 2009 21:23:09 +0900

terminal에서 vim을 띄워서 작업한다면 K 키로 man page를 보는 데 그다지 문제가 없다. 물론, 터미널이 제대로 된 터미널일 경우에.

그런데 gvim을 쓸 때에는 K 키로 man page를 보면 보기 싫게 나온다. less가 화면을 제어하기 위한 기능이 gvim에서 제공되는 emulated terminal에서는 제공되지 않기 때문이란다. (관련링크) 그래서 Dr Chip이라는 사람이 vim 창에서 자체적으로 man page를 출력해주는 vim plugin은 만들었다. man page viewer라는 것으로 man page를 보려는 keyword 위에서 K 키를 누르면 터미널에서 man이 구동되지 않고 vim 창이 쪼개지면서 새 창에 man page가 나온다. 새로 나오는 창은 일반적인 vim buffer처럼 동작한다. (간단히 말해서 h,j,k,l 키로 이동. ctrl+d, ctrl_u 등도 이용 가능. 등등등)

설치는 아주 간단하다. 일단 위 링크를 눌러서 Dr Chip의 페이지로 간 다음에 Man Page Viewer를 우클릭해서 어딘가에 저장한다. 요즘 왠만한 데스크탑용 vim이라면 확장자가 .gz인 파일을 그냥 열 수 있다. 그러니 그냥 vim으로 manpageview.vba.gz를 연다. 그런 다음에 :so % 라고 입력한다. (:부터 %까지 다 입력해야 함.) 이렇게 하면 ~/.vim 아래에 이런 저런 파일들을 생성한다. 다음부터는 gvim에서 K 키로 man page를 "잘" 볼 수가 있다.

ps. 찾아보니 KLTP에 이와 관련된 팁이 이미 있었는데 (이 글) 너무 오래된 (2002년) 글이다.

2009년 우분투 세미나

Lbird — Mon, 11 May 2009 01:23:30 +0900

우분투 한국 사용자 모임에서 "2009년 우분투 세미나" 를 개최합니다.

이 세미나에서는 우분투를 처음 접하는 사용자와 우분투를 사용하고 있는 사용자들을 대상으로, 우분투 소개, 데스크탑 설정 및 응용 프로그램 등의 기초적인 부분과 리눅스 커널 및 DBMS 등의 고급 내용도 함께 다룰 예정입니다. 또한 상당한 수준의 기념품이 (가능한) 참석자 전원에게 지급될 예정입니다. 더 자세한 내용은 다음 글을 참고하세요. viewtopic.php?f=2&t=5063&start=0

주의 : 세미나 참석 인원이 정원에 도달하였으므로, 추가 신청은 받지 않습니다. 하지만 기념품을 못받더라도 오시겠다! 하시는 분은 오셔도 됩니다.

라고 합니다. 이상 펌! ^^

저도 참석할 예정입니다.

Ubuntu에서 노트북 배터리 아끼기

Lbird — Thu, 7 May 2009 12:40:51 +0900

노트북 배터리를 아끼기 위한 첫번째 step은 뭐니 뭐니해도 일단은 powertop을 설치하고 어떤 것들이 노트북에 로드를 주느냐를 감시하는 것이다. powertop은 추가로 배터리를 아끼기 위한 이러저러한 방법들을 추천해 준다. 그런데 ubuntu의 경우에 laptop-mode-tools라는 것이 있어서 powertop이 추천해줄만한 것들이 이미 설정되어 있다. 사용자의 취향에 따라서 세세하게 조정할 수도 있다. GUI는 일단 모르겠다. 기본적으로는 /etc/laptop-mode/laptop-mode.conf 를 수정하는 방식이다. (현재 설치된 Ubuntu는 9.04임)

laptop-mode 설정

/etc/default/acpi-support 수정해서 ENABLE_LAPTOP_MODE=true 로 변경함. 이 것이 laptop-mode-tools에서 하는 작업들을 사용할 수 있게 해줌. laptop-mode-tools의 설정 파일은 /etc/laptop-mode/laptop-mode.conf 에 있는데 대충 설정들을 보면 전력 소모를 줄일 수 있는 설정들이 대부분 들어가 있는 것으로 보인다.

/etc/laptop-mode/laptop-mode.conf 내의 몇가지 option들을 enable한다.

CONTROL_NOATIME=1
CONTROL_HD_WRITECACHE=1

/etc/laptop-mode/conf.d/ 아래에 있는 conf 파일들에서 쓸모 있을 것 같은 설정들을 enable시킨다.

ac97-powersave.conf
bluetooth.conf
configuration-file-control.conf
dpms-standby.conf
ethernet.conf
hal-polling.conf
intel-hda-powersave.conf
intel-sata-powermgmt.conf
lcd-brightness.conf

echo [value] to echo 5
BRIGHTNESS_OUTPUT="/sys/class/backlight/acpi_video0/brightness"

sched-mc-power-savings.conf
usb-autosuspend.conf
video-out.conf

BATT_DISABLE_VIDEO_OUTPUTS="VGA"
LM_AC_DISABLE_VIDEO_OUTPUTS="VGA"

wireless-iwl-power.conf

이건 enable하지 않았다. 설정 파일의 설명에 의하면 iwl4965 driver를 사용할 때 효과가 있다고 하는데, 현재 나의 경우 iwlagn driver를 사용하고 있다.

Reducing disk activities

아래는 사실 위에 것을 하기 전에 찾아본 것인데, 누구에겐가는 쓸모가 있을 것 같아서 덧붙인다.

에... 그러니까, conky가 report하기로 disk에 뭔가 계속 쓰여지고 있다고 한다. 이런 저런 명령어들을 찾아봤는데 무슨 process가 얼마나 (그리고 어디에) 쓰고 있는지 알려주는 것이 없는듯했다. 그러다가 이글(https://answers.launchpad.net/ubuntu/+question/30513)을 발견했는데 아래쪽에 보면 iotop이라는 프로그램(http://guichaz.free.fr/misc/#iotop)을 소개하고 있다. 이게 딱 내가 찾던 것인데... 문제는 이 프로그램도 어떤 프로세스가 disk에 접근하는 정도는 보여줘도 어떤 파일을 읽거나 쓰는지는 안 보여준다.

googling하다가 이런 글(http://ubuntuforums.org/showthread.php?t=839998)도 발견했다. journal commit과 page 교환 간격을 늘려주는 것이다. 그런데 이것대로 따라하고 나도, suspend 갔다가 돌아오면 sysctl.conf 의 설정은 원래대로 덮어쓰여진다.

ubuntu wiki에 보면 이런 것(https://wiki.ubuntu.com/ReducedPowerUsage)도 있다. 2006년 글인데 아직도 쓸모가 있을 것 같다.