2009년 11월 16일 월요일

[latex] verbatim에서 tab을 인식하도록 하려면?

latex에서 코드 등을 넣기 위해는 verbatim을 쓰는 것이 하나의 방법이다. verbatim을 이용하면 자동으로 고정폭 폰트를 사용하므로 코드를 삽입하기에 알맞다. 그러나 verbatim은 tab을 표현해주지 않는데, 가끔 indentation이 space가 아닌 tab으로 된 코드를 복사한 후에 latex compile을 하면 indentation이 전혀 표현되지 않아 난감한 경우가 있다.

이 경우에는 다음과 같이 해결할 수 있다.
\usepackage{moreverb}
를 우선 선언한다. moreverb가 설치되지 않았을 때는 따로 설치해야 한다. ubuntu의 경우에는 기본 패키지에 포함되어 있지 않으므로 다음 패키지를 설치해야 한다.
sudo apt-get install texlive-latex-extra
그리고 verbatim이 필요할 때,
\begin{verbatim} ... \end{verbatim}이 아닌,
\begin{verbatimtab} ... \end{verbatimtab}을 이용하면 된다.

tab size는 기본적으로 8이며, 이를 조정하고 싶을 때는 다음 명령어를 문서 앞에 두면 가능하다. 예제는 4로 변경한다.
\def\verbatimtabsize{4\relax}
숫자를 필요에 맞게 변경하자.

2009년 11월 13일 금요일

emacs & go

go language는 emacs에서 편집하기 위해 go mode를 제공한다. 그 밖에 vim과 xcode를 위한 모드를 제공하고 있다.

go를 설치한 폴더를 보면 misc폴더가 있는데(go/misc), emacs, vim, xcode 폴더가 있는 것을 알 수 있다.

emacs/ 에는, go-mode.el과 go-mode-load.el이 위치하고 있다.
(setq load-path (cons (expand-file-name "~/go/misc/emacs/") load-path))
(load-library "go-mode")
(setq auto-mode-alist (cons '("\.go$" . go-mode) auto-mode-alist))
를 .emacs에 추가하자.
물론 load-path에 있는 경로는 자신이 go를 설치한 곳으로 변경해주어야 한다.
이제 .go 파일을 열면 go mode가 적용되는 것을 볼 수 있다.

ps.
속도를 위해서는 바이트 컴파일 해두는 것이 좋을 것이다. 바이트 컴파일 하는 법은 여러 가지가 있지만 emacs에서 폴더를 열고 파일 리스트가 나오면 파일에 대고 대문자 B를 누르면 간단히 할 수 있다. 마우스로 하려면 Operate 메뉴를 눌러보자. Byte-compile이 있을 것이다.

.emacs

백업을 위해, 현재 사용하고 있는 .emacs 파일을 남겨둔다.

(custom-set-variables
  ;; custom-set-variables was added by Custom.
  ;; If you edit it by hand, you could mess it up, so be careful.
  ;; Your init file should contain only one such instance.
  ;; If there is more than one, they won't work right.
 '(TeX-PDF-mode t)
 '(current-language-environment "UTF-8")
 '(default-input-method "korean-hangul3f")
 '(default-korean-keyboard "3f" t)
 '(show-paren-mode t)
 '(transient-mark-mode t))
(custom-set-faces
  ;; custom-set-faces was added by Custom.
  ;; If you edit it by hand, you could mess it up, so be careful.
  ;; Your init file should contain only one such instance.
  ;; If there is more than one, they won't work right.
(set-background-color "#242424")
(set-foreground-color "#f6f3e8")
(set-cursor-color "#656565")
(set-face-foreground 'font-lock-comment-face "#99968b")
(set-face-italic-p 'font-lock-comment-face t)
(set-face-foreground 'font-lock-doc-face "#99968b")
(set-face-italic-p 'font-lock-doc-face t)
(set-face-foreground 'font-lock-constant-face "#e5786d")
(set-face-foreground 'font-lock-string-face "#95e454")
(set-face-italic-p 'font-lock-string-face t)
(set-face-foreground 'font-lock-variable-name-face "#cae682")
(set-face-foreground 'font-lock-function-name-face "#cae682")
(set-face-foreground 'font-lock-type-face "#cae682")
(set-face-foreground 'font-lock-builtin-face "#8ac6f2")
(set-face-foreground 'font-lock-keyword-face "#8ac6f2")
(set-face-foreground 'font-lock-preprocessor-face "#e5786d")
(set-face-foreground 'font-lock-negation-char-face "#e7f6da")
(set-face-foreground 'link "#8ac6f2")
(set-face-bold-p 'link t)
(set-face-underline-p 'link t)
(set-face-foreground 'show-paren-match "#f6f3e8")
(set-face-background 'show-paren-match "#857b6f")
(set-face-bold-p 'show-paren-match t)
(set-face-foreground 'region "#f6f3e8")
(set-face-background 'region "#444444")
(set-face-foreground 'lazy-highlight "black")
(set-face-background 'lazy-highlight "yellow")
 )

;(register-input-method
; "korean-hangul3f" "Korean" 'quail-use-package
; "한3" "한글 3벌식 최종: Hangul input method"
; "quail/hangul3f")

;; 세벌식 최종
(custom-set-variables
'(default-input-method "korean-hangul3f"))

;; AucTeX
(load "auctex.el" nil t t)
(load "preview-latex.el" nil t t)
(setq TeX-auto-save t)
(setq TeX-parse-self t)

;; Clean Emacs
(setq make-backup-files nil)
(setq inhibit-startup-message t)

;; Hangul Input
(global-set-key [?\S- ] 'toggle-input-method)

;; no beep
(setq visible-bell t)

;; go to the line
(global-set-key [(f5)] 'goto-line);

;; fontset
;(set-default-font "-misc-droid sans mono-medium-r-normal--12-0-0-0-m-0-iso8859-1")
;(set-fontset-font "fontset-default" 'korean-ksc5601 "-microsoft-gulim-medium-r-normal--12-0-0-0-p-0-ksc5601.1987-0")
(set-default-font "Droid Sans Mono-10")
(set-fontset-font "fontset-default" 'korean-ksc5601 "Gulim-10")

;; header identification
;; c, c++, objective c 소스 파일이 있느냐에 따라 헤더의 mode를 결정
(defun my-header-file-mode-hook ()
  (if (string-equal (file-name-extension buffer-file-name) "h")
      (let ((filebase (file-name-sans-extension buffer-file-name)))
        (cond
         ((file-exists-p (concat filebase ".m"))
          (objc-mode)
          )
         ((file-exists-p (concat filebase ".c"))
          (c-mode)
          )
         ((file-exists-p (concat filebase ".cpp"))
          (c++-mode)
          )
         ((file-exists-p (concat filebase ".cc"))
          (c++-mode)
          )
         ((file-exists-p (concat filebase ".mm"))
          (objc-mode)
          )
         (t
          (objc-mode)
          )
         )
        )
    )
  )
(add-hook 'find-file-hook 'my-header-file-mode-hook)

;; compile
(global-set-key [(f7)] 'compile)
(setq compilation-window-height 12)

;; 컴파일 창 자동으로 사라지도록 하는 것
;(setq compilation-finish-function
;      (lambda (buf str)
;    (if (string-match "exited abnormally" str)
;        ;;there were errors
;           (message "compilation errors, press C-x ` to visit")
;      ;;no errors, make the compilation window go away in 0.5 seconds
;         (run-at-time 15 nil 'delete-windows-on buf)
 ;        (message "NO COMPILATION ERRORS!"))))

;; go lang
(setq load-path (cons (expand-file-name "~/go/misc/emacs/") load-path))
(load-library "go-mode")
(setq auto-mode-alist (cons '("\.go$" . go-mode) auto-mode-alist))

2009년 11월 12일 목요일

Go Language를 설치해보자.

구글이 go라는 언어를 발표했다.

우선은 리눅스와 맥만을 개발 환경으로 두고 있는 듯 하다. Python과 C++을 합쳐 놓았다는 기사가 있었는데, 잠깐 살펴본 바로는 둘과 크게 상관은 없는 것 같다. 파이썬의 생산력과 C++의 속도를 모두 잡겠다는 것이 의도라고 go의 개발자들이 이야기하고 있는데, 그것을 강조해서 말하다 보니 오해를 불러 일으킬 수 있는 기사가 나간 것 같다.

이것은 잠시 딴 이야기지만 파이썬과 C++에 대한 언급은 조금 경솔했다고 생각한다. 개발자들에게 언어라는 것은 매우 민감해서 이런 발언이 긍정적인 효과를 불러올 확률은 매우 낮다. 두 언어를 다 모르는 사람에게는 호기심을 자극할 수도 있겠지만, 파이썬 개발자나 C++ 개발자는 "흥, 얼마나 잘난 언어일까?"하고 삐딱한 마음을 가질 가능성도 높다고 생각한다.

아직은 초창기이고 이름에 대한 논의까지 멈추지 않았으니 성숙하려면 한참은 걸릴 것 같다. 홈페이지를 둘러본 바로는 라이브러리가 꽤 잘 되어 있는 것 같고 문법도 깔끔한 편인 것 같으니 어떻게 성장해 나갈 지 흥미롭게 지켜볼 수 있을 것 같다. 게다가 뒤에는 구글이 있지 않은가!

설치를 해보자.

리눅스(ubuntu 9.10)를 사용하고 있기 때문에 설치를 해보고 샘플로 제공하는 hello, world를 해봤다. 설치법은 go 홈페이지에 잘 나와있다.

$GOROOT, $GOOS, $GOARCH 환경 변수를 설정해준다.
좀 더 친절하게 예를 들자면, .bashrc 파일 뒤에다가
export GOROOT=~/go
export GOOS=linux
export GOARCH=386
를 넣어주면 되겠다. 홈 디렉토리에 /go라는 디렉토리를 만들고 그 곳에 필요한 파일을 다운로드 하겠다는 것이고, 운영체제는 리눅스, 32비트라는 의미가 된다. go 언어 개발자들은 주로 64비트에서 실험을 하는 듯 하다. 가장 안정된 arch가 amd64(64-bit) 포트, 그 다음이 386(32-bit)이라고 말하고 있다.

한 가지 홈페이지에서 제안하는 환경 변수가 더 있는데 $GOBIN이다. go 언어의 컴파일러와 링커 등이 설치될 경로를 설정하는 변수인데, 지정하지 않을 경우 ~/bin 이 사용된다. 내 경우에는 홈디렉토리에 bin 디렉토리를 두고 있고 몇몇 스크립트 파일과 rar등을 넣어두고 있기 때문에 설정하지 않았지만 go를 /usr/bin이나 /usr/local/bin에 넣어두고 싶은 사람은 설정해두어야 할 것이다.

내 생각에는 시스템 폴더에 넣는 것은 그리 좋은 방법이 아닌 듯 하다. permission 문제도 있고. 그냥 ~/bin을 쓰는 것이 가장 좋을 듯.

$ hg clone -r release https://go.googlecode.com/hg/ $GOROOT
라고 입력하면 소스를 죽 받아오게 되는데, Mercurial이 필요하다. 설치되지 않은 경우에는 우분투라면,
sudo apt-get install mercurial
로 간단히 설치할 수 있겠다. 다른 배포판에서는 알아서들.

go 디렉토리가 생성되게 되는데, go/src에 가보면 all.bash라는 파일이 있다. 실행하자. 한 번에 설치를 해주는 스크립트이다.
$ ./all.bash
한참을 작업하고는
--- cd ../test
0 known bugs; 0 unexpected bugs
$
라는 메시지와 함께 설치가 종료된다.

홈페이지에는 컴파일러의 실행 파일이 6g이지만 386 포트를 사용하게 되면 8g가 실행 파일이 된다.
package main

import "fmt"

func main() {
    fmt.Printf("hello, world\n")
}
$ 8g hello.go
$ 8l hello.8
$ ./8.out
hello, world
$
에러가 없기 때문에 아무 메시지도 출력되지 않는다. 8g는 컴파일러, 8l은 링커이고 기본 실행 바이너리의 이름은 8.out이 된다. hello, world가 깔끔하게 출력!

일단은 설치가 간편하고 깔끔한 느낌은 든다.

2009년 11월 5일 목요일

Bash history를 tcsh 스타일로

매번 까먹는 녀석. 백업용으로 블로그에 기록.

화살표키(up-arrow, down-arrow)로 현재까지 입력된 내용을 바탕으로 history search를 한다.

cat ~/.inputrc
"\e[A":history-search-backward
"\e[B":history-search-forward


2009년 11월 3일 화요일

a chicken-and-egg situation

Key exchange와 authentication에 대한 이야기를 하고 싶어, 제목을 이렇게 붙였지만, 이 문제가 닭이 먼저냐 달걀이 먼저냐 하고 물어볼 문제는 사실, 아니다. 당연히 key exchange가 먼저다. 아니, 이렇게 말할 것이라면 왜 제목을 이렇게 달았나?

좀 더 이야기를 해보자.

우선, "둘이 무슨 관계인가?" 싶은 사람이 있을 수 있기 때문에, 약간 일반적인 이야기를 꺼내보자. 생판 모르는 누군가의 신원을 증명하려면 what you know나 what you have를 통해 일반적으로 점검한다. 각각, 패스워드(암호, 무엇을 알고 있는가?)와 신분증(무엇을 가지고 있는가?)이 대표적인 예다.

통신을 하려 하는데, 상대방이 믿을 만한 녀석인지 알 방도가 없다. 서로 간에 내가 착한 놈이라는 것을 증명을 해야 하는데, 그러려면 증명할 어떤 것이 필요하다. 서로를 증명하기 위해서는 둘만 알고 있는(가지고 있는) 확실한 어떤 것이 필요한데, 이것을 여기서는 secure token이라고 하자. 이 secure token을 어떻게 나누어 가질 것인가? 이것이 정말로 어려운 문제다. 그래서 제목처럼 애매한 상황이 발생하는 것이다.

상식적으로 생각해보자. 당연히 secure token은 아무도 모르는 공간에서 둘만 만나서 은밀하게 결정하면 된다. 하지만 컴퓨터들은 physical contact를 하기 보다는 네트워크로 연결되어 있다. 네트워크가 안전하다는 보장을 위해서는 다시 secure token이 필요하므로(secure token을 key로 사용하여 데이터를 암호화 할 수 있을테니까) secure token을 안전하게 공유하기 위해서는 secure token이 필요한, 머리가 복잡한, 물고 물리는 상황이 연출되고 마는 것이다.

1976년에 Diffie와 Hellman이 멋진 수학식을 제시했다. unsecure channel에서도 안전하게(즉, 둘만 아는) 정보를 나누어 가질 수 있게 된 것이다. 그 이름도 유명한 Diffie-Hellman Key Exchange(Agreement)이다.

하지만 이것은 꽤나 복잡한 수학 계산을 필요로 한다. 모바일 기기의 중요성이 대두됨과 동시에 아직 그들의 성능이 뛰어나지 못한 관계로 사람들은 Diffie-Hellman을 사용하지 않고 시스템을 설계해보려고 많은 노력들을 하고 있다. 조그만 센서가 Diffie-Hellman을 사용할 수는 없기 때문이다. 좋은 논문 주제가 되는 것이다.

네트워크가 안전하지 않다면, 아직까지는 Diffie-Hellman외에는 획기적인 방법이 없다. 더 적은 계산량으로 도청꾼이 가득한 통신 채널을 통해서 어떻게 하면 안전하게 secret을 나누어 가질 수 있을까?

Any idea?

2009년 10월 29일 목요일

보안과 네트워크

Inspired by Bob Blakley's THE EMPEROR'S OLD ARMOR (1996)

보안에서 reference monitor라는 개념이 있다(많은 정의가 있겠지만 그 중 간단한 것을 하나 적으면 다음과 같다. access control concept that refers to an abstract machine that mediates all accesses to objects by subjects. 출처) 주체가 객체에게 시도하는 모든 접근을 감시한다는 것인데, 군대에서 보초 서는 것을 떠올리면 된다. 내가 보초를 서면서 지키려고 하는 울타리가 있을 것이고 외부에서 누군가 접근하면 암호를 묻는다. 누가 오든 모든 사람에게 다 묻는다. 그걸 통과해야만 울타리 안으로 들어오는 것이다. 울타리의 모든 영역은 보초병이 감시한다. 사각(쥐구멍)은 없다고 가정한다.

이렇게 간단한 개념에 reference monitor라는 이름을 붙여 놓으니 참 어려워 보인다. 이것은 information fortress라고 불리기도 한다. fortress라는 단어가 붙은 건 위에서 말한 '울타리'를 떠올리면 감이 올거고. 이 개념은 '지켜야 할 것'이 1) 굉장히 소중할 때, 2) 몇 개 없을 때, 3) 고립된 상태에서도 잘 활용될 수 있을 때 적합하다. fortress라는 용어 자체가 이런 조건을 암시하고 있다.

하지만 컴퓨터 보안에서 이런 시절은 갔다. 컴퓨터는 점점 더 싸지고 네트워크로 연결되고 있으니까.  컴퓨터는 몇 대 없었고 그들에게 접근하는 것은 매우 어려웠던 옛 시절이 떠오르지 않나? 잘 연결된(well-connected) 네트워크를 상상해보라. 요새에 개구멍이 슝슝 뚫리는 그림이 보이지 않는가. 요새에 문이 몇 개 없을 때는 그 문만 잘 지키면 되었는데, 이제 문이 너무 많은 것이다. 문이 너무 많은 성벽이라. 꼭 벽이 있어야 할까? 하는 의문이 들만 하다. 인터넷은 광장이 되었다. 요새는 무너지고 광장만 남았다. 모든 것이 open된 세상. 아름답다.

하지만 보안은 힘들어졌다.

문지기 몇 명만 고용하면 되었던 옛 시절은 가고 치안 유지를 위한 순찰대를 고용해야 했다. 훨씬 더 많은 숫자가 필요하고 따라서 많은 비용이 들어간다. 보안은 '완벽(perfection)'을 추구해야'만'하는 분야인데 비용은 더 많이 들어가면서도 치안은 더 힘들어졌다. 예전엔 문지기가 잘 지켜주기만 하면 요새 안은 평화로웠으나 이제는 순찰대가 열심히 순찰을 다녀주어도 사각에서는 범죄가 발생하기 때문이다.

2009년 10월 23일 금요일

Good advice

Silver Bullet Talks with Bob Blakley를 읽다가.

Blakley는 1994년 매우 힘든 시기를 보내고 있었다고 한다. 모든 것이 마음대로 되지 않았던 그 때, Ellen McDermott에게 투덜대고 있으니 그녀가 이렇게 말했다고.

Well, why don't you quit whining about it and do something?
(음, 그만 징징대고 뭘 좀 하지 그래?)

아. 당연한 말이지만 정답이지 않은가?

Bob Blakley도 이렇게 생각했다고 한다.

Well, that's actually good advice.

2009년 10월 22일 목요일

Settle down?

이글루스, 네이버, 티스토리에도 있어봤고, 개인 서버에도 돌려보고, 친구 서버에 기생도 해봤다. 참으로 많은 곳을 떠돌아 다녔고 자료는 하나도 백업하지 않았다. 백업하지 않은 것이 후회될만큼 좋은 자료를 블로깅하지는 않았지만, 잘 축적되어 있었다면 어땠을까 하는 생각이 들 때가 있다. 친구들의 블로그나 혹은 유명인의 블로그를 보면 archive에 상당한 양의 글이 쌓여 있으니까.

이번에는 친구따라 텍스트큐브에 계정을 만들어본다. 이번에는 확실히 컴퓨터에 대한 이런 저런 생각과 이야기를 적어보면 어떨까 싶다. 그 동안 중구난방 개인적인 이야기나 관심사를 적어왔는데, 어느덧 블로그라는 것이 그런 공간이 아닌 것처럼 변해가더라. 개인적인 이야기는 마이크로 블로깅을 하면 될 것 같았는데, 요즘 트위터를 보면 그 마저도 전문 지식의 공유 공간 같이 변해가더라. 그나마 미투데이가 내게 그런 공간을 제공해주고는 있지만.

그동안 블로그를 따로 써야할 필요를 느끼지 못했다. 사진은 플리커에 올리고 있고, 간단한 일상은 미투데이에 적어두니까. 그래도 가끔은 긴 글을 써야 할 때가 있더라. 귀찮기도 하고 참아왔는데, 생각을 정리하고 정성을 다해 기록해두는 것은 - 분명 시간을 빼앗기는 작업이지만 - 앞으로 나가기 위한 추진력이 되는 것 같다. 김창준님이 말씀하셨던 회고(retrospective)의 위력을 가끔씩 느낀다. 도움이 된다는 것을 알면서도 귀찮기 때문에 아무것도 하지 않았지만, 매일 일기를 쓰면 하루가 정리되고 다음 날 할 일이 눈에 보이듯이 머리 속에서 잠시 정리할 시간을 갖는 것은 꼭 필요하다는 생각이 들었다. 가끔 자기전에 정리하면 좋더라고.

이게 내가 블로그를 다시 여는 핑계다.

2009년 8월 12일 수요일

IE8이 계속 죽을 때.

IE8이오류창을 계속 띄우면서 결국은 접속에 실패하는 경우가 발생한다면, 한글(워드프로그램)을 설치하지 않았는지 기억을 되돌려보자. IE8을 설치하고(또는 업그레이드하고) 한글을 설치하면 IE8에서 이런 현상이 발생할 수 있다.

한글이 설치된 상황에서 IE8을 설치하는 것은 괜찮다고 하더라. 직접 실험해본 것은 아니다.

해결책은 IE8을 다시 설치하는 것이다. 프로그램 제거를 할 필요는 없다. 제거를 시도하면 오히려 IE8관련 업데이트들 때문에 꼬일 수 있다. 설치 파일을 microsoft 홈 페이지로부터 다운 받아서 설치하겠다고 하면 된다.



2009년 7월 28일 화요일

SLIME에서 REPL이 뜨지 않을 때.

언제부터인지는 모르겠지만 cvs로 slime을 받아서 시작하면 REPL이 뜨지 않는다.
디폴트로 뜨지 않도록 바뀌었다고 하는데, 다음과 같이 하면 이전처럼 REPL을 띄울 수 있다.

.emacs에 있는
(slime-setup) 대신에,
(slime-setup '(slime-repl)) 로 수정하면 된다.

사족) Aquamacs 사용자는 ~/Library/Preferences/Aquamacs Emacs/Preferences.el 에서 수정하면 된다.

2009년 7월 27일 월요일

정보의 자살

보안(security)만큼 프라이버시(privacy)에 대한 논의도 많은 요즘.

프라이버시는 결국 데이터의 축적(archiving)이 그 이유라고 생각해.
데이터가 축적되지 않으려면 어떻게 해야 될까?

데이터에 시한 폭탄을 달 수 있을까? 그래서 자살하는거야. 축적되지 않도록.
하지만 데이터라는 것은 코드에 의해서 다루어지는 성질의 것이니 스스로 자살한다는 것이 말이 안 되지 않나.

예전, 자바 코어 책에서 이런 것을 봤었는데,
프로그램 = 알고리즘 + 데이터
오브젝트(객체) = 데이터 + 알고리즘
이라고 생각하라고 하더라고.
그 때 받아들이기로는 데이터에 더 무게를 준 것이구나 정도로 생각했었는데, 객체지향이라는 것이 데이터가 더 능동적으로 행동할 수 있도록 해줄 수 있는 것이 아닌가 생각되더라.

그렇다면 모든 데이터를 객체 안에 담고(encapsulation) 사용을 하되 자살 루틴이 포함되면 된다는 것인데,
사용할 때마다 특정 프로시져를 구동해야 하도록, 데이터를 얻고자하는 루틴, 즉, getter/setter에 필요한 루틴을 강제시키는 것이 일단 보기에 간단한 해결책일 수 있지.
문제는 코드를 강제한다는 것이 쉬운 것이 아니니 말이야. 얼마든지 우회할 수 있는 길이 있겠지.

우선의 설계는,

1) 반드시 데이터를 사용할 때 initiation을 해야 한다.
2) 데이터를 사용할 때 get을 해야 얻을 수 있다. get할 때마다 시간이 점검되어 expire되면 자살하거나, 사용 회수를 점검하여 자살한다. (zero나 random string으로 자신을 채워 자살할 수 있겠지)

다음은 perl로 구현해본 코드.

privateData.pl



use strict;

package main;

my $data_instance = PrivateData->new("Top Secret");
print "First Try: ", $data_instance->get(), "\n";
print "Second Try: ", $data_instance->get(), "\n";
print "Third Try: ", $data_instance->get(), "\n";

0;

package PrivateData;

sub new {
my ($self, @args) = @_;
my $obj = {
_data => $args[0],
_used => 0,
_limit => 1,
};
bless $obj, $self;
return $obj;
}

sub get {
my ($self) = @_;
$self->_data_used();
$self->_suicide() if $self->_expired();
return $self->{_data};
}

sub _data_used {
my ($self) = @_;
$self->{_used}++;
}

sub _expired {
my ($self) = @_;
return ($self->{_used} > $self->{_limit}) ? 1 : 0;
}

sub _suicide {
my ($self) = @_;
$self->{_data} = "Trash";
}

1;

__END__

결과는 다음과 같다.

First Try: Top Secret
Second Try: Trash
Third Try: Trash

동일한 세 번의 코드이지만 다른 결과를 얻을 수 있다.
객체의 힘이고, 객체지향을 알고 있는 사람에게는 당연한 소리지만, 노출되면 곤란한 데이터(private data)를 다루기에 좋은 모델임은 틀림없다.

당연한 소리를 관점만 살짝 바꾸어 이야기하고 나니 뭔가 부끄럽네.

2009년 7월 15일 수요일

MS Office 2010 Web?

기사 출처: http://www.pcmag.com/article2/0,2817,2350110,00.asp

- 오피스 2010이 웹 버전이 나온다는 이야기.
- 개인에게는 공짜로 제공될 것이라 함.
- 구글 독스를 겨냥한 것.
- 내 예상으로는 구글 독스보다 기능이 훨씬 많을 것.
- 안정적이면서도 빠른 반응을 보일 수 있을 것인가?

- 그렇다고 오프라인 버전을 만들지 않겠다는 것은 아님.
- 오프라인 버전이 더 많은 기능과 좋은 성능을 보일 것은 당연.
- 오피스를 사용하기 위해 윈도우를 사용하는 일도 있는데 이젠 다른 OS에서 접근 가능한 걸까?
- 파이어폭스와 같이 IE가 아닌 브라우저에서 접근이 완벽히 가능하게 될까?
- 그렇게 된다면, 비 윈도우 사용자에게는 행복한 이야기가 될 것.
- 하지만 실버라이트라도 쓰는 날에는?
- 맥에서는 겨우 쓸 수 있겠네.
- 오픈 된다면 오픈 오피스가 타격을 입을 수도?
- 윈도우에서만(IE에서만) 가능하다면 오픈 오피스에게는 여전히 기회가.

- 웹으로 흘러가는 흐름에 있어 엠에스 입장에서는 불가피한 결정이었을까?
- 과연 옳은 결정일까?
- 일반 사용자들의 불법 복제는 막을 수 없다는 판단이었을까?
- 구글 독스나 오픈 오피스에 익숙한 사용자를 만들지 않기 위한 방편일 수도 있다.
- 개인 사용자들이 쓰게 만들고 널리 이용되면서 결국에는 기업에서 살 수 밖에 없도록.
- 윈도우와 다를 것 없는 전략이면서도 진부하지 않은 효율적인 전략.
- 기업에 제공하게 될 유료 웹 오피스도 저장 공간 제공 등의 서비스로 추가 이익을 창출할 수 있겠지.
- 그것 말고도 돈 받아낼 아이템을 많이 생각해두지 않았을까? 무엇일까?

2009년 7월 9일 목요일

Google Chrome OS에 대한 이야기를 듣고 개인적 정리.

> 구글 크롬 운영체제에 대한 이야기를 7월 8일 처음 접함
> 보자마자 드는 생각: 크롬은 웹브라우저인데 왜 운영체제도 이름이 크롬인거야?
- 곰곰히 생각해보면 그건 당연한 것.
- 구글은 웹이라는 곳에서 사는 녀석이니까
- 웹브라우저가 곧 그들에게는 운영체제 (다시 말해서 플랫폼)
여기서 가지게 되는 의문, "과연 웹이 플랫폼이 될 수 있을 것인가?"
> "사람들은 컴퓨터로 무엇을 하나?"를 생각해 볼 필요가 있음.
- 모든 것을 나열할 수 없으니, 내가 하는 것만 대충 나열.
  • 메일, 메신저, 뉴스
  • 게임
  • 문서작업(위드나 한글, 엑셀, 파워포인트 작성)
  • 음악 만들기
  • 뱅킹, 쇼핑
  • 프로그래밍
> 크게 두 가지로 나눠볼 수가 있겠다. 이미 웹으로 하고 있는 것, 아닌 것.
> 웹으로 지금 하고 있지 않은 것을 모두 웹에서 할 수 있게 되면 웹이 곧 플랫폼이 되겠지.
- 게임, 프로그래밍 등은 현재 웹에서 잘 하지 않는 것.
- 특히 게임은 많은 자원을 필요로 하기 때문에 웹에서 동작하는 것이 쉽지 않을 것이고, 그럴 필요도 없다고 생각 됨.
하고 싶은 말: 모든 것이 웹에서 동작할 수는 없을 것이고 그럴 필요도 없다고 생각.
> (운영체제) 크롬은 어떤 모양일까. 전체 화면에 (웹 브라우저) 크롬만 덩그러니 떠 있는 것?
- 개인 파일은 어떡하지?
  1. 내 하드 디스크가 있고 file:// 로 접근? 지금처럼 (텍스트) 목록으로 보여주지 않고 (그래피컬하게) 폴더를 보여주는 것은 어렵지 않을 것. 다른 프로그램의 실행도 가능하게 할 수 있을 것. 스타크래프트를 실행한다거나.
  2. 하드가 없는 디바이스? 구글이(또는 다른 스토리지 서비스가) 내게 개인 폴더를 제공. 아! 이것이야 말로 그리드 컴퓨팅?
> 1번이 가능성이 높을 것. 내 개인 데이터를 다른 사람이 관리하는 곳에 맡겨두는 것이 간단하지는 않을 것.
결국, 웹 브라우저가 무조건 떠 있지만 다른 네이티브 바이너리도 동작할 수 있도록 하는 방식?
> 이것은 현재의 OS와 차이가 없다라고 말할 수도 있음.
어쨌든, 웹 브라우저와 파일 탐색기가 결합된 형태 정도의 수준이 우선은 되지 않을까 개인적 전망.
> 내 경우, 컴퓨터를 켜고 파이어폭스를 켠 뒤, 컴퓨터를 끌 때까지 파이어폭스를 닫지 않음.
- 음악을 듣거나 latex로 문서를 만들 때를 제외하고는 거의 모든 작업을 웹에서 하고 있음.
> 많은 어플리케이션이 웹에서 아름답게 동작하는 날이 올 것이지만, 몇몇 무거운 프로그램들이 여전히 남아 있을 가능성이 높다고 판단.
- 게임을 비롯해서 그래픽, 음악 작업 시 사용되는 소프트웨어, 시뮬레이션 도구 등등.
> 웹이 플랫폼이 되려면 이와 같은 프로그램들은 클라이언트에 설치되어 클라어언트의 자원을 사용할 수 밖에 없을 것.
- 다시 자바 애플릿 같은 메커니즘이 나올까?
- 보안 문제는 어떻게 해결하게 될까.
더 이상 상상은(헛소리는) 그만하고 어떤 모습으로 나올지 우선은 지켜보자.

2009년 7월 8일 수요일

DDoS 관련 기사들을 보고.

- 오늘 DDoS 공격 관련 기사를 몇몇 봤음.
- 국내 정부 사이트와 몇몇 포탈, 미국의 몇몇 주요 기관을 공격하고 있는 듯. 총 26개 사이트?
- 이 사이트들 신나게 맞고 있는 것 같은데, 대응을 제대로 못하고 있다고 비난 기사을 보게 되어서... 불쌍한 마음이 들어 이 글을 쓰기 시작.
- DDoS가 원래 좀 막기 어렵다는 말을 하고 싶었음.
- 지금 공격 맞고 있는 사람들, 방어하느라 고생 많을 것. 안 그래도 힘든데 욕하지는 말자.
- DDoS가 아닌 단일 호스트에서의 DoS도 사실 막기 쉽지 않음. IP 차단하면 되지 않느냐 쉽게 생각할 수 있지만 IP Spoofing도 가능하다는 것이 문제.
이건 라우터들이 다음 것만 체크해주면 될텐데. "나가는 패킷의 source IP address가 진짜 내가 데리고 있는 놈인가?". 근데, 안 해.
- Flooding-based DoS를 유발하는 패킷은 정상 접속 request와 차이가 없다는 점에서 또 어려움.
특히나 HTTP는 요청 메시지인 GET이 복잡하지 않아서 메시지를 까서 검사해도 비정상을 구분하기 쉽지 않을 것. (사실, 요 부분은 잘 모르고 떠드는, 추측. 열폭 자제 부탁.)
- DoS도 이러할진데 DDoS는? (단순하면서도 효율적이니까) 많이 이용하는 rate-limit(비정상적이게 많은 패킷이 오면 더 안 받는거나 차단하거나 하는 거)로도 감지가 안 되도록 할 수 있음. 여러 호스트가 살금살금 패킷 보내면 어떡할거야.
- 스타 중계를 항상 보면 나오는 말이 있음. "물량엔 장사가 없어요". 공3업 아칸도 저글링 개때를 막을 수는 없음.
- 기사보면, 백신 최신으로 업데이트하라고 하는데 그건 의미가 별로 없음.
백신 데이터베이스는 signature로 구성되어 있는데 이 signature는 이미 알려진 문제점을 분석해서 얻는 것이기 때문. 일부 휴리스틱(heuristic) 탐지를 하는 anti-virus 제품을 이야기한다면 미안. (근데 그거 잘 되는게 있어?)
- 윈도우 업데이트 잘 하라고 하는데 이건 반쪽 해결책.
  • '내 컴퓨터가 좀비(zombie)가 되지 않도록 하기 위해서'라는 이유라면 타당.
  • 하지만 이미 감염되고 나면, 업데이트 또한 패치일 뿐이기 때문에 백신 디비 업데이트와 같은 이야기.
- 사후 대응일지라도 현재 진행되고 있는 DDoS를 빨리 막아내야 되는 것 아니냐라고 한다면 그 말은 옳고도 옳은 말.
- 하지만 그냥 차단하는게 빠를까 사용자가 패치(또는 업데이트) 해주길 기다리는 게 빠를까.
- 우리나라 사용자들이 업데이트 잘 안하고 백신 안 깐다고 보안 의식이 없다고 하는데, 내 생각은 그렇지 않음. 외국 애들은 항상 뭐든지 최신으로 유지할까? 별 차이 없을 것.
하나, 잘못 생각할 수 있는 것이 있는데, 최신 보안 제품이 항상 가장 안전하다는 생각은 버려.
- 아, 그리고 우리나라만큼 최신 좋아하는 곳이 어디있음?
- 우리나라가 좀비 만들기 좋은 세상인 이유 BEST 3
  • 집집마다 컴퓨터가 있다는 것
  • 근데 그 컴퓨터들이 다 인터넷에 연결되어 있다는 것
그냥 환경이 좋음. 인터넷 보급율 높다고 자랑할 땐 언제고. 반대급부니까 너무 뭐라고 그러지 말자.
- 좀비 만들기 좋은 세상, 이유 BEST 2.
Windows 운영체제의 과도한 점유율. 안그래도 컴퓨터가 많은데, exploit하나 잘 만들면 그 것들을 효율적으로 내가 조종할 수 있으니까.
- 좀비 만들기 좋은 세상, 이유 BEST 1.
우리나라 사용자들의 보안 의식에서 중요한 부분은 윈도우 업데이트 안 하고 백신 최신으로 유지 안하는 것이 아니라, (ActiveX를 중심으로) 웬만한 서비스들이 각종 경고 무시하고 무조건 프로그램을 설치하도록 교육시킨 것이 가장 문제.
설치 버튼을 무심코 누르는 순간 당신은 차가운 도시 좀비.
- 결론: DDoS는 막는게 쉽지 않다는 점을 알아줬으면 좋겠음.
DDoS는 내 지갑에 있는 돈을 슬쩍 해가는 소매치기(정밀한 칩입 기술)가 아니라 어려 명이 다굴해서 죽이는(혹은 죽을 정도로 때리고 죽인다고 협박하는) 것이라서 경계 태세를 취하고 미리 대처하고 이런 게 잘 안 통함.
- 정부부처 관계자나 포탈 보안팀이나 KISA에서 사용자 탓 좀 해도 너그럽게 이해해주길 바람.
- 별 것 아닌 공격에 쩔쩔맨다는 느낌이 드시는 분들은 대응책 관련해서 메일 부탁. (굽신굽신).
- 더 쎈 녀석을 상대하고 싶다! 하시는 분들은 "DRDoS" 구글에 찾아서 뭔지 한 번 보시고 역시 메일 부탁...
- 개인적으로 제시하는 해결 방안 1: 다양화.
어떤 ecosystem이든 다양한 종이 없으면 끝나듯, fault-tolerant system에서 여러 개의 redundancy(여러 종류의 S/W, H/W)로 극복하듯, 우리나라의 컴퓨터에 다양한 OS, 다양한 웹브라우저 정도는 깔려줘야 해.
- 웹브라우저까지 언급한 건 요즘 워낙 웹이 대세라서.
- 개인적으로 제시하는 해결 방안 2: 오픈소스.
오픈소스가 아니니 무슨 짓을 하는 지 알 수가 없고, 따라서 믿을 수가 없음. 티맥스님들 혹시 오픈소스로 풀 생각은 없음? (아, 수백억 투자했었지...)
- 구글 크롬 오에스는 오픈 소스! 꺄!
- 내 의견이 씨도 안 먹힐 거라는 것쯤은 스타크 부드러워 1.05시절부터 알고 있음.
- 개인적인 해결책에 이은 개인적인 부탁
MS 윈도 깔고 IE로 들어가야만 뱅킹하고 쇼핑하는 세상을 좀 없애주면 안 되겠니?

2009년 7월 7일 화요일

Tmax 발표를 보고.

전문 블로거도 아니고, 내가 쓰지 않아도 많은 블로거들이 리뷰를 올려주겠지만 나도 2시간 정도 이 발표를 보는데 사용했으니 소감이라도 남겨둔다.

- 오늘 티맥스 윈도9 (운영체제), 티맥스 오피스, 티맥스 스카우터(웹 브라우저)에 대한 발표회가 있었음
- 국산 운영체제와 웹 브라우저, 오피스를 만드려는 시도를 했다는 점에서 우선 큰 박수
- 오늘 발표를 요약하면 다음 2가지.
  1. 포토샵 스크린 샷이 돌아다니면서 말이 참 많은데, 우리 만들고 있는 거 뻥 아니야.
  2. 우리가 만들려는게 되게 어려운 거야~ 봐봐, 어렵지? 어렵지?
1번: 오늘 발표의 충분한 이유가 된다고 생각. 날짜는 다가왔고 소문은 이상하고 돌고. 거짓이 아님을 말하고 싶었을 것.
2번: 목표가 거창하고 어려운 작업이라는 것 백 퍼센트 공감. 어려운 작업이 반드시 필요한 어떤 것이 되지는 않음.
- 나는 이걸 왜 만드는지가 궁금함.
- 우선, 티맥스 윈도.
  • 윈도우와 리눅스 바이너리를 그대로 가져와서 쓸 수 있는 운영체제를 만들고 싶었던 듯.
  • 사실 대한민국에서 널리 사용될 토종 운영체제를 만들려면 윈도우와의 호환이 되어야 한다는 것 완전 동감. 오피스 관련 수석이 발표 때 말하지 않은 것이 있는데 마소의 오피스도 처음엔 기존에 잘나가던 오피스들과 완벽호환 되었음. 그런데 어떻게 독점을 했나? 더 좋은 기능으로 승부를 보면서, 플러스 독점적인 파일 포멧. 조엘 온 소프트웨어를 읽자.
  • 리눅스에서 동작하는 어플리케이션 중에 윈도우에서 작동하지 않아서 안타까운 것이 뭐가 있던가? 내가 아는 건 중에는 없다. ns-2(network simulator 2)를 잘 돌려주려나...?
  • 결론: 그냥 윈도우 호환만 완벽하게 하자. (데모 보니까 이것도 아직 멀었드만)
  • 본인의 추천: ReactOS의 부진한 성과에 화나서 우리가 그냥 만들어버렸어! 라고 하는 것이 훨씬 박수 많이 받을지도?
  • 스타 로딩하는데 엄청 오래 걸렸다. 내가 옛날 옛날, wine으로 스타 돌려보겠다고 설정잡고 돌렸을 때 돌아가던 스피드와 크게 차이가 없었다. 심지어 데모를 보며 의심했다. 이거 와인 아님?
- 다음은 오피스.
  • 일단 시연을 보면서 개발자들이 굉장히 삽질을 했을 거라는 것은 느껴졌음. 수고. 이혼, 불가능하지 않아.
  • 하지만 역시 의문이 들 수 밖에 없는 점, '왜 만들었지?'
  • 추측: 자신들은 ODF의 열렬한 지지자인데, OpenOffice가 MS Office 파일에 대한 호환성이 좋지 않아서 사용이 잘 안 되니 하나 만들어주겠다!
  • 본인의 가벼운 생각: 점유율을 늘리려면 독자적인 포멧을 가져. 근데, 이건 욕 먹어. 알집을 봐.
  • 본인의 추천: 엄청 싸게 팔아.
- 마지막으로 스카우터.
  • 프로토스 유저로써 작명이 불안하다. 안 쓰일까봐.
  • 레이아웃 흐트러지지 않고 잘 보이는 점은 좋았다. 근데 써볼 수 있게 공개해주면 안 돼? 어차피 윈도우에서 돌렸잖아?
  • 엑티브 엑스가 돌아간다는 점, 그래서 인터넷 뱅킹 로그인에 성공한 데모는 인상적이었지만, 데모 보여주기 전에 웹 표준이 어쩌고 저쩌고 하면서 심지어 운영체제에 독립적이고 하는 이야기는 이해할 수가 없었음. 말 실수였겠지. 그럼 FreeBSD에서 설치되는 스카우터를 만들어 주시나요? 이제 나도 인터넷 뱅킹을 할 수있겠어! (스카우터도 결국 윈도우용과 티맥스 윈도용 두 가지 버전 밖에 없을 것 아닙니까?)
- 가장 하고 싶은 말은 발표 전반적으로 느끼는 것은 지루했다는 것
잡스형이 떠올랐다. Intel Mac과 관련된 발표를 할 때 뜬금없이 MacOSX를 만지다가 현재 맥의 하드웨어 정보를 보여줬다. Intel이다. 응? 지금까지 MacOSX가 잘 돌고 있었는데? 와! 그렇구나. 이미 다 만들었구나!
- 오늘 시연도 이랬으면 어땠을까?
  • 브라우저를 열고 뱅킹을 한다. 지마켓에서 물건을 산다. 잘 된다. 어? 근데 이 운영체제가 윈도우랑 좀 다르네. 티맥스 윈도네. 브라우저 정보를 보여주는데 스카우터네.
  • 스타를 하다가 alt + tab을 누른다. 근데 윈도우가 아냐.
  • 오피스도 마찬가지. 프리젠테이션을 하다가 뜬금없이 메뉴에서 '이 프로그램에 대해' 정도를 선택해서 클릭한다. 근데 MS PowerPoint가 아니야.
- 오늘의 발표는 대중을 위한 쉬운 발표도 아니었고 전문가를 위한 기술 발표도 아니었음.
일반론적인 이야기를 하다가 뜬금없이 워드의 표 이야기하면서 GUID까지 언급하는 건 오버였다. 이건 앞에서 말한 이유, 아~ 만들다보니 어려웠어~ 하지만 우린 잘 했다구! 정도 밖에는 안 된다.
- 오늘은 실체가 있다는 것을 증명한 것으로 만족
- 몇 가지 오류가 보이는 것은 오히려 다행이라는 느낌. 진짜 뭔가 만들고는 있다는 것이니까.
- 개인적으로는 이 프로젝트가 과연 사용자의 needs가 있는지가 가장 궁금.

2009년 7월 3일 금요일

Firefox 3.5, video tag & FreeBSD

요즘 다시 프비(FreeBSD)를 쓰기 시작하면서 스스로 놀라고 있다. 의외로 윈도우(Windows)에 손을 대지 않고 있다. 데스크탑에 프비를 설치했고 노트북에 윈도우 비스타를 설치해두었다. 가급적 프비를 쓰면서 작업할 때는 비스타로 해야지 생각했던 것이다. 그런데 엠에스 오피스를 사용할 때와 한글(HWP) 파일을 사용할 때를 제외하고는 비스타를 쓸 일이 없다. (아... 스타도 하는구나)

프비를 사용하면서 불편함을 크게 느끼지 못하는 가장 큰 이유는 많은 작업을 웹에서 하기 때문인 것 같다. 파이어폭스(Firefox)가 프비 상에서 훌륭하게 동작해주기 때문에 지메일과 스프링노트 등을 사용하는데 아무런 문제가 없다. 또 Pidgin 덕분에, 엠에스엔, 구글 토크, 네이트온의 사용이 오히려 더 편하다. 셋을 하나의 프로그램에서 간단히 관리할 수 있기 때문이다. mplayer가 있기 때문에 음악 감상과 동영상을 보는데 아무런 문제가 없고 (동영상 볼 일은 거의 없지만) latex (ko.tex)가 있기 때문에 발표자료 작성이나 문서 작성에 아무런 불편함이 없다. gimp가 있어 그림 파일의 간단한 편집에도 불편함이 없고, 와콤 타블렛이 (윈도우 만큼은 아니지만) 잘 동작한다.

불편함이 하나도 없다! 라고 계속 말하고 있지만 사실 불편함은 있다. 당연하지 않은가. 대한민국에서 윈도우가 아닌 운영체제를 사용하게 되면 무조건 불편하다.

가장 큰 불편함은 역시 가장 많이 사용하는 웹 브라우저에 있다. 어도비(Adobe)가 프비용 플래시 플레이어(Flash player)를 제공하지 않는다는 점이다. 많은 동영상을 포기할 수 밖에 없다. 유투브(youtube)를 비롯해서 이젠 거의 대부분의 동영상이 웹에서 플래시를 통해 재생되니까. 차라리 Windows Media Player를 embed하던 시절이 나았다. 그러면 파일 경로 찾아서 다운로드한 다음에 mplayer로 볼 수 있었으니까.

다행이 gnash라는 괜찮은 오픈소스 플래시 플레이어가 있어서 유투브 영상은 문제 없이 볼 수 있다. 하지만 다른 대부분의 비디오 서비스는 gnash가 제대로 재생해주지 못한다. 리눅스를 쓰면 모든 것이 해결되지만(어도비가 리눅스용 플래시 플레이어를 제공한다), 프비에 대한 애정이 더 강한 것을 어찌하랴.

본론으로 들어가자. 얼마전 파이어폭스 3.5가 출시되었다. 많은 개선점이 있지만 가장 내 눈을 끄는 것은 HTML5의 비디오 태그(video tag)였다. 샘플 동영상이 내 프비에서 훌륭하게 재생되는 것이 아닌가? 아니, 이럴수가!

무척이나 반가웠다. 조금 검색해보니 샘플 동영상은 Theora 코덱이 사용되고 있었고(.ogv 파일), 비디오 태그의 목적은 플러그인이 없이도 오디오와 비디오를 즐길 수 있도록 하는 것이라 했다. 와. 정말 이런 세상이 온다면 더 이상 전 세계의 프비 사용자들이 어도비에게 플래시 플레이어 좀 만들어 주세요! 라며 굽신굽신하지 않아도 되는데.

하지만 바로 걱정이 들기 시작했다. Theora가 표준이 될 것인가? 마소의 wmv는? 애플의 mov는? 가만히 있을까? 사파리에서도, 크롬에서도, 오페라에서도, 익스에서도 다들 Theora를 구현해 넣을까?

검색해보니 아직 논란이 많은 것 같다. 우선 윤석찬 님께서 잘 정리해주신 글이 있다. 읽어보자.
또 하나 메일링에서 찾은 글이 있는데,
- 애플은 Theora를 퀵타임에 넣기를 거부
- 구글은 일단 H.264와 Theora를 크롬에 구현
- 오페라와 모질라는 H.264를 넣기를 거부
- 마소는 아무 반응이 없더라
정도의 반응을 보인다고 한다.

웹 전문가가 아니기 때문에 잘 모르고 하는 소리지만 (우선 읽은 것만으로 판단하면) 비디오 태그의 표준 코덱으로 H.264와 Theora가 논의되고 있는 것 같다 (윤석찬님의 글에서도 볼 수 있듯이 Theora를 사용하는데 있어서 노키아가 딴지를 걸고 차라리 H.264를 쓰자고 했다고 한다). 어찌되었든 많은 기업들이 연관되어 있는 상황에서 (겉으로는) 라이센스 문제나 (속으로는) 기업의 이해관계에 따라 모두들 입장이 다를 수 밖에 없을 것으로 보인다.

워낙 큰 기업들이 붙어있는 일이니 만큼 Theora로 딱 정해지지는 않을 거라는 것이 우선 드는 생각이다. 그리고 혹시 Theora가 표준이 된다고 한들 과연 그것을 사용할 지도 의문이다. 앞으로 어떻게 전개될지 상당히 궁금하다.

파이어폭스를 비롯한 오픈소스가 열심히 싸워준 덕분에 프비에서도 불편함 없이 많은 작업을 할 수 있고 이미 충분히 즐겁다. 나로써는 어떤 코덱이 승리하든 사실 별로 관심은 없고 (ogg 포멧이 널리 사용되기를 바라기는 하지만 꼭 그럴 필요는 내게 없으니까) 웹에서 비디오까지 문제 없이 즐길 수 있는 날이 오기를 바랄 뿐이다. 그렇게만 된다면 더 바랄 것이 없을 것 같다.

ps. 물론 FreeBSD용 스타크래프트 2가 나온다면? 정말로 더 바랄 것이 없겠지만. HAHA.

2009년 6월 30일 화요일

FreeBSD & Gvim

주로 사용하던 에디터는 emacs였지만, 윈도우를 한참 사용하다보니 일반적인 notepad 스타일의 에디터도 불편하지 않았다. 다시 FreeBSD를 설치하고는 적당한 에디터를 찾아봤지만 역시 emacs나 vim에 대한 강한 추억이란...

emacs를 설치하고 써보려 했지만 anti-aliasing font이 깔끔하게 표현되지 않았고, perl programming하기에는 vim이 더 편한 것 같아서 vim을 설치하기로 했다.

cd /usr/ports/editors/vim
make WITH_GTK2=YES install clean
WITH_GTK2를 하지 않으면 gvim이 GTK1을 사용하게 된다.

설치 완료 후 GTK2와 잘 조합된 모습. 컬러 스킴은 wombat을 사용했다.

2009년 6월 18일 목요일

Twitter?

Computer Science를 전공했으며 아직도 학교에 남아 같은 분야의 공부를 더 하고 있는 사람이지만 요즘의 IT 유행을 따라 가는 건 쉽지 않은 것 같다. 이제서야 비스타를 써볼 수 있는 기회가 생겼는데 윈도우 7이 나온다고 난리고, 아직도 블로그를 잘 활용하지 못하고 있는데 마이크로 블로그들이 성행하고 있다. Ubuntu의 버전은 빠르게 올라가고 있고, 잠시 FreeBSD 사용을 쉬었다 싶었더니 벌써 버전이 7.2이다.

각설하고 본론으로 들어가자. 요즘 Twitter가 난리다. 아니 난리인지 이미 오래되었다.

나는 국내 서비스 미투데이를 이용하고 있다. 미투데이라는 서비스를 처음 접했을 때 이것이 외국의 트위터라는 서비스와 유사하다는 이야기를 들었었고 그 때 찾아본 트위터는 그저 그런 서비스였다. 나름의 인기는 있었지만.

그 때와는 분위기가 달라졌다. 요즘은 트위터를 안 쓰면 뒤쳐지는 느낌이 들 정도로 주변에서 트워터에 대한 이야기를 많이 듣는다. 어쩔 수 없이 가입해보았다. 분명 쉽다는 이야기를 많이 들었는데 처음엔 뭔지 잘 모르겠더라. 검색해서 조금 찾아보니 내가 사용하던 미투데이와는 방식이 다르기 때문에 이해를 못했던 것 같다. 물론 아직 일주일도 이용해보지 않은 상황이라 서비스를 정확히 이해하고 있을리 만무하고, 따라서 글을 쓰는 것이 성급한 것이겠지만, 괜찮은 서비스인 것 같아 소개도 할 겸 글을 남긴다.

미투데이와 트위터가 어떤 서비스인지를 아직 이야기 안 했다. 둘은 모두 마이크로 블로깅을 할 수 있도록 도와주는 서비스다. 미투데이는 150자, 트위터는 140자를 남길 수 있다. 한 줄 블로그라고 생각하면 된다. 그만큼 쉽게 가벼운 이야기들을 남길 수 있다. 블로그라는 것은 갈 수록 전문화되고 있어 일반 사용자들이 쓰기에는 부담스러워져 버렸으니 이런 서비스가 인기를 얻는 것이 일리가 있다.

미투데이와 트위터 중 어느 것이 낫다는 이야기를 할 생각은 없다. 다만 미투데이를 꽤 사용해왔고 그것을 바탕으로 트위터에 대한 첫인상을 가질 수 밖에 없었기 때문에 둘의 차이점으로 이야기를 풀어가겠다.

미투데이는 가입 후 생성되는 나만의 페이지에 글을 남길 수 있다. 그리고 친구를 만들 수 있는데, 친구 신청을 하고 그 사용자가 수락하면 서로 친구가 된다. 친구로 등록되면 '친구들은'을 클릭하여 그들이 올린 글을 읽을 수 있다. 그리고 해당 글에 덧글을 달 수 있는 방식이다. 내 친구들 또한 '친구들은'을 클릭하여 자신의 수 많은 친구들이 남긴 글 중에 내가 쓴 글을 발견하게 될 것이다.

트위터 역시 가입 후 바로 내 페이지에 글을 쓸 수 있고 친구를 만들 수 있는데, 이것을 follow라고 한다. 미투데이와 조금 다른 점은 '친구들은' 버튼이 없다는 것인데, follow한 사람들, 즉 친구들이 글을 쓰면 내 Home에서 바로 보인다. 그리고 해당 글에 덧글을 달 수 있는 미투데이와는 다르게 트위터는 그런 기능이 없다. Follow라는 것은 서로 나랑 친구하자~ 하는 것이 아니라 일방적으로 그 사람이 쓴 글을 내가 구독하겠다는 의미가 된다.

정리하면, 미투데이는 친구 '신청'을 하고 '수락'해야 서로 글을 보게 되지만, 트위터는 내가 그냥 가서 엿봐야지~ 하면 볼 수 있게 된다. 이게 별로 차이가 없는 것 같지만 그렇지 않다는 생각이 들더라.

우리가 잘 아는 싸이월드의 일촌도 그렇지만 신청하고 수락하는 관계가 되면 소규모의 긴밀한 네트워크가 형성된다. 이것은 아주 재밌는 소셜 커뮤니티지만 결국 그건 폐쇄적인 커뮤니티일 뿐이다. 반면 트워터는? 완전 개방이다. 다른 사람이 내 글을 볼 수 있게 없게 제어할 수가 없다.

유명인의 페이지를 예로 들면 가장 확실히 와 닿는다. 트위터에는 김연아가 있다. 김연아가 미투데이에 계정을 만들었다고 해보자. 엄청난 친구 신청을 받을 것이다. 다 수락해주기도 힘들거다. 두 가지 경우가 있을 수 있다. 일일이 골라서 수락하거나 자동으로 다 수락하거나. 전자는 힘들 것이니 후자를 택할 확률이 높다. 자, 이제 김연아가 자기 친구들의 글을 보고 싶다. 전혀 모르는 사람들이 다 내 친구다. 이런! (트위터처럼 내 Home 화면에 보이기 시작한다면?!)

트위터에서는? 일일이 친구 수락을 할 필요가 없다. 사람들은 내 글을 엿들을 테니까. 그녀는 자기가 보고 싶은 사람의 트위터만 follow하면 된다. 내 글을 누가 보고 있는지, 누가 나에 대해서 뭐라고 하는지 알 길이 없다. 현재 이 글을 쓰고 있는 시점에서 김연아의 트위터를 follow하고 있는 사람은 - 나를 포함해서 - 만오천명 정도 되지만, 정작 김연아가 follow하고 있는 사람은 고작 6명이다. 그 6명이 쓰는 글 외에는 어떤 글도 김연아의 페이지에서는 보이지 않는다.

전에도 말한 적 있지만, 나는 comment의 효용성을 아주 낮게 보고 있다. 그런 의미에서 덧글 기능을 사용하지 않는 트위터의 손을 들어주고 싶다. 이러한 방식이 더 의미있는 커뮤니케이션 네트워크를 형성할 수 있다고 생각한다.

사실 내 주변에 사람들 중 미투데이를 사용하는 사람을 찾는 것도 힘들다. 블로그를 쓰는 친구들 중에서도 꾸준히 글을 남기는 사람이 드물다. Web 2.0의 광장에 잠시 구경왔다가 다시 나올 생각을 않는 사람들이 태반이다.

뭔가 심심한데 블로그를 쓰기에는 버거운 사람들에게 트위터는 괜찮은 서비스가 아닐까 싶다. 내가 쓴 글에 덧글이 달렸나 안 달렸나 일일이 점검하지 않아도 되고 편안하게 내가 하고 싶은 말을 재잘거리면(tweet) 되니까. 그리고 멋진 사람이 보이면 follow하자. 김연아나 버락 오바마와 같은 사람들이 있다.

ps.
본의 아니게 미투데이가 안 좋은 듯한 뉘앙스를 풍기는 글이 되었다고 생각된다. 하지만 그렇지 않다. 덧글(comment)의 가치를 매우 낮게 생각하는 본인에게는 트위터의 방식이 더 마음에 들었을 뿐이다.

ps2.
김연아가 트위터를 쓰고 있다는 이야기만 했는데, 미투데이에도 에픽하이의 tablo가 있다. :)

2009년 6월 16일 화요일

A Big Factorial Number

책을 읽다가
What are the largest values of n for which n! has fewer then 100 decimal digits, fewer than 1000 decimal digits, and fewer than 10,000 decimal digits?
라는 질문을 보고 간단히 perl script로 결과를 구해봤다.
69!, 449!, 3248!이 각각 10진수로 99자리, 998자리, 9998자리이다.

다음은 코드와 결과이다.

use strict;
use bigint;

my $d = 10000;
my ($i, $n) = (1, 1);
while(1)
{
$n *= $i;
last if length($n * $i) >= $d;
$i++;
}
print "$i factorial: $n [", length($n), " digits]\n";

69 factorial: 171122452428141311372468338881
27283909227054489352036939364804092325
7279754140647424000000000000000 [99 digits]

449 factorial: 385193051802807257632158476912
12875548395805893534467012649055767896288
926298594457881668628676415791435136187818
72021746359685290289255601854954706967037
237815981933427173547163838273480784018675
12495830429837203000813557811307516010999
35399420025859541702588941624119769786447
979635875887987628187121141743814227340405
786877075540700136227919818634007425579126
136583156012933348747449102149815962647863
834705576714179015069575989844000509497340
761230129254648880664249707996772824842574
358558533486456993617018144080838058452833
163022395716238804463454122374136551392458
4025461354677759729187297731663124277878618
877498334677521800812698843489928636349843
038102559471536632660957843998883126988557
88258154809005327539117440908208905353330
891394428678158921052069748074205537868136
717094006764031023426591318276097353833638
375226039787340475684974328746914841262748
8289694186769477953126400000000000000000
0000000000000000000000000000000000000
0000000000000000000000000000000000000
0000000000000 [998 digits]

3248 factorial은 너무 길어서 생략.

Ulam numbers

정수론 책을 보다가 Stanislaw M. Ulam (1909-1984)라는 사람의 소개를 읽게 되었다. 폴란드 출신 학자로 물리학, 천문학 등에 관심이 있었으며 미국 여러 대학을 돌아다니며 연구하고 강의했다고 한다. 특히 핵폭탄을 만드는데 큰 공헌을 했다고.

이 사람이 만든 Ulam numbers라는 정수 수열이 있는데, 두 개의 정수(일반적으로 1,2)를 시작으로 한다. 피보나치 수열이 단순히 앞의 두 수를 더해서 다음 값을 결정하는 것에 비해 Ulam numbers는 조금 더 복잡하다.

Ulam number는 두 개의 Ulam number의 합이 되는데, 대신 정확히 한 쌍의 Ulam numbers의 합한 결과여야 하며 숫자의 중복 사용은 허가되지 않는다. 예를 들어 설명하는 것이 가장 빠르겠다.

{1, 2}가 시작 숫자였다. 1+2 = 3. 3은 Ulam number이다.
{1, 2, 3}이 얻어졌다. 1 + 3 = 4. 4도 Ulam number이다. 2 + 2 = 4이지만 중복 사용은 안 된다.
{1, 2, 3, 4}가 얻어졌다. 1 + 4 = 5 이지만 2 + 3 = 5 이기 때문에 5는 Ulam number가 아니다.

이렇게 계속 구해나가면 수열이 만들어지며 이것이 바로 Ulam numbers이다.

Ulam numbers를 구하는 perl script를 작성해보았다.

use strict;

my @seq = ulam(seed => [1, 2], max => 100);
print "@seq\n";

sub ulam()
{
my %args = @_;
my @ulam = @{$args{seed}};
my $max = $args{max};
my ($i, $j) = (0, 1);
my @dups;
while(1)
{
my $s = $ulam[$i] + $ulam[$j];
push @ulam, $s;

if($i + 1 == $j)
{
$j++; $i = 0;
my (@dup, %seen);
foreach (@ulam) { push @dup, $_ if $seen{$_}++ } # find duplications
push @dups, @dup; # save duplications
foreach (@dups) { $seen{$_}++ } # update the duplication record
my @dup_removed;
foreach (@ulam) { push @dup_removed, $_ if $seen{$_} == 1 } # remove duplications
@ulam = sort {$a <=> $b} @dup_removed;
last if($ulam[$j] > $max);
}
else
{
$i++;
}
}
$#ulam = $j - 1;
return @ulam;
}


100까지의 Ulam numbers를 구하는 코드인데, 결과는 다음과 같다.
1 2 3 4 6 8 11 13 16 18 26 28 36 38 47 48 53 57 62 69 72 77 82 87 97 99
위키피디아에 보여지는 것과 동일한 결과를 얻을 수 있었다.

ps.
프로그램에 주석이 없어 추가 설명을 간략히 적어둔다.
i와 j는 두 수를 더하기 위한 인덱스이다. (0, 1) (0, 2) (1, 2) (0, 3) (1, 3) (2, 3) (0, 4) ... 와 같이 진행된다. 항상 i가 j보다 작으며 i가 j보다 1작은 수가 되면 j가 하나 증가하면서 i는 0가 된다.
Ulam number는 내부 숫자의 합이므로 일단 더해서 배열에 저장해둔다.
j가 증가되기 바로 전 시점에 중복으로 나타나는 값을 점검하고 제거한다.
중복 출현한 숫자는 모두 기억하고 있어야 한다. 여러 번 계산 결과로 출현할 수 있기 때문이다.

ps2.
코드를 이쁘게 보여줄 수 있는 방법이 있으면 좋으련만.

2009년 6월 9일 화요일

세벌식에 대한 이야기.

1990년 컴퓨터를 처음 접한 이후로 사용했던 한글 자판은 - 당연히 - 2벌식이었다. 당연하게 사용하던 자판을 바꿔볼까 싶었던 것은 4년전쯤이다. 그 때 문득 별로 할 일이 없던 휴일에 세벌식을 연습해보겠다고 타자 연습 프로그램을 켜두고 삽질을 했던 기억이 난다. 쉽지 않았다. 10년이 넘도록 사용하던 자판을 바꾼다는 것은.

연습했던 자판은 "세벌식 최종"이었다. 세벌식을 연습하러다 보니 자판 종류가 많았다. 뭘 해야하지? 하면서 구글링이라도 했어야 했는데 그냥 "최종"이라니까 이게 가장 좋아보였다.

얼마전에 알게 된 것이지만 공병우 박사님께서는 수 많은 최종 버전 자판을 만드셨단다. 돌아가시기 전에 만드신 것이 세벌식 391이며 이 때도 최종이라고 붙이셨는데 돌아가시고 나니 이게 그냥 최종이 되었다는 글을 본 적이 있다. (믿거나 말거나) 결론적으로 하고 싶은 말은 '최종'이라는 이름이 이 자판이 가장 좋기 때문에 최종이라고 붙은 것은 아니라는 것이다.

많은 자판이 있지만 가장 많이 이용되는 세벌식 자판은 390과 391이다. 앞에서도 말했든 391은 최종이라는 이름으로 더 많이 불린다. 390에 대해서는 뒤에 이야기하겠다.

세벌식 자판은 한글 입력에 있어서는 정말로 편리하다. 두 벌식은 초성과 종성을 모두 왼손이 담당하고 있는데 세벌식은 초성, 중성, 종성이 모두 다른 자판으로 배치되어 있어 리듬감 있는 타자가 가능함은 물론 일명 "모아치기"가 가능해진다. 무슨 말이냐 하면 피아노 치듯 동시에 3키를 눌러도 한글이 입력이 된다는 것이다.

'글'을 입력하기 위해서는 초성 ㄱ를 담당하는 쿼티 자판 K, 모음 ㅡ를 담당하는 G, 받침 ㄹ을 담당하는 W를 동시에 눌러서 입력을 할 수 있다. 동시에 누른다는 건 사실 불가능한 것이므로 다시 말하면 세 키를 누르는 순서가 달라도 입력이 잘 된다는 것이다. 받침, 모음, 초성으로 입력해도 글자가 잘 입력된다.

당장 실험해보고 '어? 안되는데?' 하는 사람이 있을 수 있다. 마이크로소프트사가 제공하는 기본 한글 입력기는 이 모아치기가 지원되지 않는다. 따라서 '새나루'나 '날개셋' 입력기를 설치하는 것이 세벌식을 최대한 활용할 수 있는 방법이다. 새나루의 경우 XP에서 매우 잘 동작했으나 현재 내 VISTA에서 설정 저장 문제가 있어 사용이 거의 불가하고, 날개셋은 아주 잘 동작하고 있다.

세벌식을 한 번 연습해볼까? 하는 사람이 있다면 세벌식 390도 나쁘지 않다. 넘어오는데 더 편할 것으로 생각된다. 세벌식은 앞에서 말했듯 초중종성을 모두 따로 배열해두었다. 따라서 키가 모자란다. 숫자키가 더 이상 숫자키가 아니며 한글 입력에도 숫자키를 이용한다. 이것은 390이든 391(최종)이든 마찬가지이다. 최종 자판의 더 큰 문제는 기호 자판 또한 모두 다르다는 것이며, 심지어 $, %와 같은 기호는 아예 없다. 390자판은 다른 기호 자판이 영문 쿼티 자판과 거의 비슷하다. 느낌표(shift + 1)을 제외하고는 shift + 숫자를 통해 입력하는 모든 기호가 같으며 <, >등이 조금 다를 뿐 나머지도 거의 동일하다. 기호를 동일하게 만드는 대신 몇몇 이중받침을 포기했기 때문에 두벌식 입력하듯이 이중받침을 두 번 타이핑하여 입력해야 하는 문제가 발생하긴 한다.

사실 최종을 쓰다가 390을 발견하고 '아! 이게 더 좋겠구나!' 했었다. 하지만 익숙해진 자판을 바꾸는 것은 역시 쉽지 않았으며 '옳', '맑'과 같이 비교적 많이 쓰이는 단어를 입력할 때 리듬이 깨지는 것이 맘에 들지 않아 다시 최종으로 돌아왔다.

두 자판 중에 어떤 것을 선택할 것인가는 사용자의 마음인 것 같다. 어느 것이 더 우수하다라고 하기에는 각각이 장단점이 있다.

한글 타이밍을 많이 하는 사람이라면 세벌식으로 이동하는 것을 강력히 추천한다. 세벌식을 쓰다가 두벌식 타이핑을 하면 확실히 왼손이 피곤하며, 특히 한글에서 빈번하게 사용되는 ㅆ받침이 두벌식은 shift와 함께 입력해야 하는 반면 세벌식은 한 번의 타이핑으로 입력되다는 점이 내가 세벌식을 떠나지 못하는 이유다.

2009년 6월 7일 일요일

블로그를 쓰다 만 이유 그리고 다시 이 글을 쓰는 이유

- 처음 쓰기 시작한 이유

블로그라는 것은 분명 내 기억에 weB LOG라는 의미였다. 일기장에 쓰던 것을 웹에 쓴다는 느낌이었달까. 실제로 블로그 초창기에는 그냥 내가 오늘 뭘 했네, 뭘 느꼈네 그런 것을 쓰는 것이 일반적인 것이었다. 나 역시 그랬고 많은 사람들이 그랬다.

- 점점 쓰지 않게 되었지

일기장은 남에게 보여주는 것이 아니다. 아주 개인적인 일은 블로그에 쓰기 애매했다. 그러다보니 남이 알아도 상관없는 이야기들을 쓰는데, 일반적으로 이런 건 별로 흥미가 없다. 정말 친한 친구들이 아니면 읽을 일이 없겠지. 게다가 반복적인 일상에서 다이나믹하게 사건 사고가 발생할리 만무하다. 쓰는 사람도, 읽는 사람도 슬슬 지겹다. 가까운 사람들조차 덧글 하나 남길 생각이 들지 않는 글들이 올라온다. 공간은 황폐해져 간다. 소통의 느낌은 없다. 블로그 쓰는 것을 멈췄다.
(한 때는 매우 개인적인 이야기까지 올렸던 기억이 난다. 웃음이 난다.)

- 블로그에 대한 불만

블로그를 쓰다보니 불만이 생겼었다. 나는 덧글 시스템이 싫다. 어떤 사람이 글을 쓰면 RSS를 통해 쉽게 새 글이 등장했음을 알 수 있다. RSS가 처음에 나왔을 때 정보가 나를 찾아오네 어쩌네 하면서 난리를 쳤는데 (기술적으로는 별 거 아니지만) 나도 그 아이디어에 박수를 보낸다. 덕분에 매우 편리하게 지인들이나 좋아하는 사람들의 글을 빠르고 편하게 읽을 수 있다. 하지만 덧글은 뭔가 부족하다. 블로그에 올라오는 좋은 글은 분명 신명나는 토론을 일으킬 수 있는 공간이며 많은 정보와 의견이 오고 갈 수 있는 장이 된다. 하지만 그러기에는 너무 불편하다. 모든 덧글을 RSS처럼 받나? 그것은 깔끔한 솔루션이 아니다.

위키는 어떤가? 위키는 좋은 글이 사라지는 것을 막고 중복을 줄일 수 있는 좋은 수단이다. 그러나 "새 글"이라는 느낌이 없다보니 새로운 콘텐츠를 원하는 사람들의 입맛에 맞지 않는 것 같다. 위키파디아가 그런 것처럼 지식 창고를 만들고자할 때는 분명 용이하지만 개인적인 이야기를 담기에는 프레임이 너무 크다. 지멋대로의 백과사전을 만들던 베르베르정도의 배짱이 있지 않다면.

뭐가 있을까? Web 2.0이라는 용어가 나온지도 꽤 오랜 시간이 지났다. 하지만 나는 아직도 블로그가 웹 2.0의 철학에 맞아떨어지는 어플리케이션은 아니라고 생각한다. 도대체 어떤 방식이 있을 수 있을까?

- 그동안 안 쓰면서 뭘 했나

그래도 뭔가 사람들과 소통하고 싶어서인지 아니면 뭔가 주절대고 싶었던 것인지 미투데이도 해보고, 스프링노트에 뭘 끄적이기도 했다. 뭔가 정리를 하고 싶은 것이 있으면 구글 독스에 써두기도 했다.

블로그라는 것은 어느덧 전문적인 지식을 가진 사람들이 글 쓰는 공간이 되어버린 느낌이 들었다. 별다른 주제도 없이 글을 쓰는 것은 의미 없다고 생각했고, 특정 주제를 잡아보려 했지만 나는 그만큼의 글을 쓸 수 있는 전문가도 아님을 알게 되었다.


- 그래도 다시 글을 쓰는 이유

다시 글을 쓰는 이유라고 하니까, 절필했던 대작가가 다시 붓을 잡는 것마냥 거창하다. 미안.
이유를 대보자면, 아니 변명을 해보자면,
아직 블로그를 대체할 만한 것을 생각해내지 못했으니까.
혼자 문서를 쓰고 정리하는 것보다는 공개하고 집단 지성으로부터 따끔한 지적을 받는 것이 더 좋을 것 같다는 생각이 들었으니까.
그리고 심심하니까.