Changwoo's Hacks

http://cwryu.textcube.com

아직도 헝가리언 스타일이 유행하고 있는 ODBC 관련 코드를 보기 싫었지만 대충 동작:


여담이지만, 큐브리드는 현재 코드로는 패키징 불가능이다. 다운로드에 있는 RPM 패키지도 만들어진 모양으로 볼 때 (root 권한으로 셸 들어가서 실행하는 대모험을 할 게 아니라면) 분명히 안 돌아간다. 현재와 같이 한 폴더에 라이브러리, 클라이언트, 서버, 데이터까지 몰아 넣고 서로 엮여 있는 현재의 모양으로는 SE가 고객의 전화를 받고 출동해서 깔아 주는 경우라면 상관없을 지 몰라도, 패키징과 시스템 연동 측면에서는 환영받지 못한다. DB 포맷, 통신 프로토콜, 라이브러리 인터페이스 모두 버전 사이의 호환성을 보장하지 않고 있기 때문에 인터페이스를 만들기도 쉽지 않다. 더 문제가 되는 라이선스 충돌 문제를 해결했으니 다행이지만 큐브리드 프로젝트는 갈 길이 멀다.

제한적 본인 확인제 등 규제로 인한 제약도 거리끼는 부분이다. 특별히 정치적인 입장을 드러내지도 않고, 불법이나 명예훼손에 관련되지도 않기 때문에 거리낄 일은 없지만, 귀찮고 기분 나쁜 일은 누구에게든 생길 수 있는 일이므로 벗어나고자 한다. 정책적 방향이 바뀌지 않는 한 어디로 탈출하더라도 이 제도는 계속 확대되겠지만 되는 데까지 버텨 본다.

진짜 불편한 부분은, 대형 포털의 고질적인 문제로, 아무리 문제점을 피드백해도 전달이 안 된다. 고객 센터는 매우 친절하게 대응했지만 사용법을 헤매는 고객을 돕는 방법만 교육 받았지 문제점 해결을 전달하는 교육은 받지 못한 모양이다. 나는 형식적인 친절함을 원하는 게 아니라 문제의 실질적인 해결을 원한다. 아무리 구체적으로 버그의 원인을 설명해도 잘 모르겠으면 "전화 주시면 해결해 드리겠습니다"라고 결론이 나면서 단답형으로 처리가 끝나는 상황은 답답하기 짝이 없다. 물론 블로그 사이트가 프리소프트웨어도 아니고 피드백을 하면서 고쳐 쓸 생각을 하는 게 잘못일지도 모르겠지만 답답한 상황은 벗어나고 싶다.

피드백이 안 된다는 것과 더불어 변화가 느린 것도 피로하게 느껴진다. 문제점 중에는 태터툴즈/텍스트큐브에 이미 반영된 사항도 있었기 때문에 더 그렇게 느껴진다. 만약 내가 티스토리 개발 방향을 결정할 수 있는 사람이었다면, 개발 조직을 대형 포털의 체계 속에 집어 넣어 격리시키는 게 아니라, 태터툴즈/텍스트큐브 오픈소스 프로젝트에 적극적으로 참여함으로써 문제를 해결하려 했을 것이다. 지금은 갈라선 지 오래 되어서 너무 늦었을까?

어쨌든 TNC가 맨 처음 티스토리를 시작할 때 내세운 티스토리의 장점은 그것이었다. 회사가 사용자를 컨트롤하지 않는 블로그. 별도의 도메인을 허락하고, 페이지 내용의 다양한 커스터마이즈를 허락하고, 티스토리를 떠나더라도 백업이 쉽다. 새삼 이러한 방향의 결정은 옳았다는 걸 느낀다. 백업 파일 포맷이 그 사이에 달라졌다는 이야기도 있지만 (1) 불가능하지는 않겠지..

역시 DejaVu 만한 게 없다. DejaVu Sans Mono와 폭을 맞추자. 방법은 다른 곳에 많이 설명되어 있으니 생략하고, 그 과정을 앞으로도 써먹을 수 있도록 스크립트로 만든다.

http://gist.github.com/60908

$ fontforge -script nanum2munan.pe NanumGothicCoding-Bold.ttf
Copyright (c) 2000-2008 by George Williams.
 Executable based on sources from 00:29 GMT 29-Apr-2008.
 Library based on sources from 20:49 GMT 30-Apr-2008.
Input File: NanumGothicCoding-Bold.ttf
Output File: MunanSansMono-Bold.ttf
Family: Munan Sans Mono
Fullname: MunanSansMono-Bold
$ fontforge -script nanum2munan.pe NanumGothicCoding.ttf
Copyright (c) 2000-2008 by George Williams.
 Executable based on sources from 00:29 GMT 29-Apr-2008.
 Library based on sources from 20:49 GMT 30-Apr-2008.
Input File: NanumGothicCoding.ttf
Output File: MunanSansMono.ttf
Family: Munan Sans Mono
Fullname: MunanSansMono

Munan은 OFL에 따라 이름을 바꾼 것. :-) 폭이 바뀌면서 자간이 늘어나 버렸기 때문에 이상적인 형태는 아니지만 그렇다고 스케일하면 힌팅이 망가질게 거의 확실하다.

실제로 Vera / DejaVu 호환을 목적으로 만들어진 글꼴도 있는데 Arundina 타이 글꼴이 그 경우이다. 한글 글꼴보다야 만드는 난이도는 낮지만 Vera / DejaVu에 호환되도록 만들어졌다. 이왕이면 기존 글꼴들과 잘 어울리게 만든 글꼴이 있으면 fontconfig에서 사용할 시스템 글꼴로는 이상적인 형태가 아닐까? (역시 디자이너들은 버럭하겠지만)

리눅스에서 많이 사용하고 있는 File Hierachy Standard 는 전통적으로 유닉스에서 사용되던 표준 파일 시스템을 명백히 표준으로 정의한 것이다. 유닉스나 리눅스 사용자라면 익숙하다 못해 친근하기까지 한 /lib, /bin, /sbin, /usr/bin, /usr/share, /usr/lib 따위의 구조는 영원히 없어지지 않는 성역이라고 생각하기 쉽지만, 이제 근본적으로 바뀔 때도 되지 않았을까? 과거의 유닉스 플랫폼의 사정이 오늘날에도 적용이 될까?

유닉스 파일 시스템의 구조는 몇 가지 목적을 가지고 만들어졌다.

• 부팅과 최소한의 관리에 필요한 파일 (/), 시스템 설치 파일 (/usr), 사용자 설치 파일 (/usr/local) 구분으로 공유 가능
  
• 아키텍처 의존 파일과 (/usr/lib) 독립 파일을 (/usr/share) 구분해서 독립 파일을 여러 아키텍쳐 컴퓨터 사이에 네트워크로 공유 가능
• 읽기 전용 파일시스템, 시스템 설정, 데이터 파일 시스템 구분 (/usr, /etc, /var 구분)

정말 공유하는 사람이 있나요?

큰 목적은 "파일 시스템의 공유 가능"이다. 부팅에 필요한 파일은 컴퓨터마다 필요하지만 /usr 아래의 대부분은 공유할 수 있다. 아키텍처가 다른 컴퓨터 사이에는 일부 파일은 공유할 수 없지만 /usr/share 따위는 공유할 수 있다. 오호라! 진짜? 요즘 세상에 이렇게 공유하는 곳이 있을까?

거의 10년 전 학교의 컴퓨터 실에는 이런 식으로 설정된 몇 대의 스팍 서버가 있었다. 하지만 이러한 멋진 구조 덕분에 최악의 안정성을 자랑했다. single point of failure, 한 머신이 죽으면 그 파일 시스템을 공유하는 모든 서버가 동작 불가능이었다. 실제로 그 서버 구성의 최대 장점은 홈 디렉토리의 공유였지 /usr 따위의 공유가 아니었다. /usr의 공유는 /usr 파일 시스템의 크기가 크고, 스토리지의 가격이 비쌀 때 가치가 있지만 용량도 커지고 가격도 내려간 지금의 하드디스크에서 /usr 파일 시스템이 공유할 만큼의 가치를 지니지 않는다.

그리고, 오늘날의 실정을 여러 모로 보면 리눅스 파일 시스템에서 /usr를 공유할 수 있다는 말은 거짓말이다. /usr/include를 보면 각 아키텍처에 의존하는 값이 잔뜩 들어 있는 헤더가 가득하고, 패키징 시스템은 /usr/share와 /usr/lib 에 동시에 파일을 설치한다.

정말 /usr 파일 시스템을 읽기 전용으로 별도 파일 시스템에 마운트해서 여러 컴퓨터 사이에 같은 아키텍처인지 아닌지에 따라 /usr/share와 /usr/lib을 구분해서 공유하는 곳이 있기는 할까? 아무리 네트워크 파일 시스템을 널리 사용하는 곳도 홈 디렉토리 공유나 대용량 스토리지 구현을 위해 사용하지 "비교적 작은" 크기의 /usr 디렉토리를 읽기 전용으로 마운트하려고 사용하는 곳은 본 적이 없다. 10년 전의 그 학교 컴퓨터 실에서도 아키텍처별로 구분하지는 않았다.

과거의 잔재

한편 /usr/X11R6 및 /usr/games라는 구조가 남아 있는데  /usr/X11R6는 X11 및 CDE/XView 따위가 굉장히 커다란 소프트웨어였던 시절에나 의미있는 구분이었다. 이제 X.org 프로젝트는 이 구조를 따르지 않는다. (/usr/X11R6/bin은 /usr/bin으로 가는 심볼릭 링크이다.)  /usr/games, /var/games같은 경우에는 BSD의 잔재인데 FHS 문서에 따르면:

The separation allows local control of backup strategies, permissions, and disk usage, as well as allowing inter-host sharing and reducing clutter in /var/lib

백업 방식을 다르게 하기 위해서, 권한을 다르게 하기 위해서, 컴퓨터 사이에 점수 따위를 공유하기 위해서, /var/lib 크기를 줄이기 위해서라고 되어 있다. 이 역시 오늘날의 실정과 맞지 않는다.

바꿀 필요가 없으니까?

굳이 전통적으로 잘 써 왔고 각종 툴이 잘 지원하는 지금의 파일 시스템 구조를 바꿀 필요가 있을까?

일단 현재의 문제는, 소프트웨어 바이너리 패키지의 유연성이 떨어진다. 현재 조금 복잡도가 높은 리눅스 소프트웨어들은 빌드타임에 데이터가 들어 있는 디렉터리가 보통 하드 코딩되어 있다. RPM 패키지의 경우 /usr, /usr/local을 선택할 수 있는 relocatable 패키지를 만들 수 있는 기능이 있지만 이렇게 경로를 하드 코딩하는 애플리케이션들은 relocatable하게 만들기 어렵다. 현재의 파일 시스템에서는 바이너리 패키지만으로 같은 애플리케이션의 여러 버전을 동시에 설치하거나 사용자에 따라 다른 애플리케이션을 설치한다거나 하는 유연성이 없다.

애플리케이션별로 별도의 경로로 설치하면 명령어 실행 경로라든지 ($PATH), 맨페이지, 폰트처럼 한 프로그램이 사용하는 데이터를 여러 패키지에서 설치하는 경우에 문제가 생기지만, 해결 방법은 있다. 한 디렉토리 안에 파일을 몰아 넣지 않더라도 파일시스템의 기능을 통해 여러 경로의 내용들을 한 곳으로 자동으로 합치는 기능이 있다. (이름이 생각이 안 나서 검색 불가...)