링크: 우분투 Japanese UI에 잘못된 번역이 있네요
좀 뒷북이지만... 일단 일본이나 중국에서 朝鮮語라고 칭하는 건 북조선을 가리키기 때문이 아니라 조선 시대부터 오랫동안 그렇게 불러 왔기 때문일 것이다. 중국이 오늘날도 서울의 도시 이름을 100년 전의 명칭이자 속국의 의미가 들어 있는 한성(漢成, 漢나라의 마을)이라고 칭하는 것처럼 진짜 모욕적인 용어도 있지만, 적어도 조선어는 차별적이거나 모욕적인 의미를 가진 용어는 아니다. 글쎄, 그런데 꼭 나라 이름과 언어 이름을 맞춰야 되나? 외국어에서 어떻게 쓰는 것까지 신경 쓰면서 살아야 되나?
서양 사람들이 부르는 Korea나 Korean이라는 이름 역시 올바른 명칭은 아니다. 심지어 조선 시대에 조정에서는 서양에서 온 공문에 수신자가 Korea라고 써 있다고 반송한 적도 있다고 한다. 고려는 자기들이 멸망시킨 패배자들의 이름이니까. 지금은 남북한 모두 자국어 공식 명칭은 대한민국/조선민주주의인민공화국으로 완전히 다른데도 공식 영문 명칭은 마찬가지로 Korea라고 하고 있으니 아이러니하다. 아예 통일되면 거기에 맞춰 국호를 꼬레아라고 하는 게 무난할 것 같다고 말하는 학자들도 있으니...
사람이 교류하는 단위, 같은 언어가 통용되거나 분화하는 과정이 국가와 관계가 있으니, 국가와 언어는 밀접하게 관계되어 있기는 하다. 하지만 꼭 그렇게 일대일 대응이 되지도 않는다. 페르시아라는 이름을 사용한 제국이 사라진 지가 천 년도 더 지났고 수많은 국가가 생겨나고 없어졌지만 아직도 그 지역의 공식 언어는 페르시아어이다. 쿠데타가 일어나든 분리독립을 하든 나라 이름이 바뀔 때마다 거기에 맞춰 전세계 어학 교과서의 제목을 그 나라 이름에 맞춰 줘야 하는 지는 의문이다.
2009년 3월 15일 일요일
2009년 3월 14일 토요일
KMPlayer FFMPEG의 Hall of Shame에 등록
FFMPEG 프로젝트에서는 Hall of Shame이라는 이름으로 GPL/LGPL 위반자 목록을 정리해 놓는데.. GOM플레이어에 이어 KMPlayer도 새로 등록되었다.
FFMPEG에서 문제 삼는 이유는, 전에도 내가 썼던 글 (KMPlayer - 정말 GPL 위반 맞을까?) 중에서 명백하게 위반한 부분, 배포할 때 GPL/LGPL 바이너리 코덱을 소스 없이 배포한 사실 때문이다.
해결하자고 마음 먹는다면 (그리고 다른 의심스러운 부분이 위반이 아니라고 자신할 수 있다면) 이 부분은 사실 너무 쉽게 해결할 수 있다. 해당 소스를 묶어서 같이 배포하면 되는 일이다. 이 소스 코드를 고쳤든 안 고쳤든 GPL/LGPL에 따르면 소스 코드를 배포해야 한다는 사실은 변함이 없다.
(업데이트) 해당 이슈 트래커 항목을 보면 GPL 심볼을 레퍼런스하는 부분도 지적하고 있다. 역시 전에 썼던 이야기 중에서 아마도 위반일 거라고 했던 부분.
FFMPEG에서 문제 삼는 이유는, 전에도 내가 썼던 글 (KMPlayer - 정말 GPL 위반 맞을까?) 중에서 명백하게 위반한 부분, 배포할 때 GPL/LGPL 바이너리 코덱을 소스 없이 배포한 사실 때문이다.
해결하자고 마음 먹는다면 (그리고 다른 의심스러운 부분이 위반이 아니라고 자신할 수 있다면) 이 부분은 사실 너무 쉽게 해결할 수 있다. 해당 소스를 묶어서 같이 배포하면 되는 일이다. 이 소스 코드를 고쳤든 안 고쳤든 GPL/LGPL에 따르면 소스 코드를 배포해야 한다는 사실은 변함이 없다.
(업데이트) 해당 이슈 트래커 항목을 보면 GPL 심볼을 레퍼런스하는 부분도 지적하고 있다. 역시 전에 썼던 이야기 중에서 아마도 위반일 거라고 했던 부분.
2009년 3월 12일 목요일
OSS 정책 - 디지털교과서 사업이 맨드리바를 부정복제?
메타냅, 한국소프트웨어진흥원에 디지털교과서용 리눅스 부정복제 중지 촉구
맨드리바 리눅스 배포판은 100% 오픈소스 버전인 Mandriva Free와 non-free 소프트웨어가 포함된 Mandriva One으로 나뉘어져 있다. 전자의 경우는 물론이고 후자의 경우도 일부를 제외하고는 모두 오픈소스 라이선스이고 사용이나 재배포를 금지하지 않는다. (단 맨드리바 상표에 대해서는 이득을 취하는 행위에 대해 이의를 제기할 수 있겠지만 메타냅 측이 지금 문제 삼는 부분은 아니다.)
그럼 과연 메타냅에서 주장하는 "부정복제"는 과연 무엇일까? 아마도 바이너리만 카피해서 배포하는 GPL 위반 행위를 말하는 것 같다. 현재 도를 넘어선 임베디드 업체들의 GPL 위반 상황을 생각해 보면 어떤 위반인지 충분히 예측할 수 있다.
하지만 왜 메타냅 측은 어떤 부분을 위반했다고 정확히 지적하지 않는 건가? 기자의 손을 거치면서 의미가 왜곡되었는지도 모르겠지만, 기사에는 어떤 이유로 GPL 위반이라는 것인지에 대해 설명하지 않았고, 오픈소스를 알지 못하는 사람들이 이 기사를 읽는다면 디지털교과서 사업에서 마치 맨드리바 측의 소프트웨어를 불법 복제한 것처럼 이해하기 쉽다.
위 기사에서 언급한 커널/드라이버/라이브러리 따위를 복제했다는 사실은 GPL에서 허용하는 것이고 위반이 아니다. GPL 위반이 문제라면 소스코드가 없다거나 라이선스를 명시하지 않았다거나 따위의 위반한 사항을 구체적으로 말해야 하지 않을까? 디지털 교과서의 컨텐츠 포맷에 특정 업체의 독점 포맷을 사용한 정책적 방향에 대해 비판할 수는 있어도 (나 역시 반대하지만), 역시 GPL 위반은 아니다.
맨드리바 리눅스 배포판은 100% 오픈소스 버전인 Mandriva Free와 non-free 소프트웨어가 포함된 Mandriva One으로 나뉘어져 있다. 전자의 경우는 물론이고 후자의 경우도 일부를 제외하고는 모두 오픈소스 라이선스이고 사용이나 재배포를 금지하지 않는다. (단 맨드리바 상표에 대해서는 이득을 취하는 행위에 대해 이의를 제기할 수 있겠지만 메타냅 측이 지금 문제 삼는 부분은 아니다.)
그럼 과연 메타냅에서 주장하는 "부정복제"는 과연 무엇일까? 아마도 바이너리만 카피해서 배포하는 GPL 위반 행위를 말하는 것 같다. 현재 도를 넘어선 임베디드 업체들의 GPL 위반 상황을 생각해 보면 어떤 위반인지 충분히 예측할 수 있다.
하지만 왜 메타냅 측은 어떤 부분을 위반했다고 정확히 지적하지 않는 건가? 기자의 손을 거치면서 의미가 왜곡되었는지도 모르겠지만, 기사에는 어떤 이유로 GPL 위반이라는 것인지에 대해 설명하지 않았고, 오픈소스를 알지 못하는 사람들이 이 기사를 읽는다면 디지털교과서 사업에서 마치 맨드리바 측의 소프트웨어를 불법 복제한 것처럼 이해하기 쉽다.
위 기사에서 언급한 커널/드라이버/라이브러리 따위를 복제했다는 사실은 GPL에서 허용하는 것이고 위반이 아니다. GPL 위반이 문제라면 소스코드가 없다거나 라이선스를 명시하지 않았다거나 따위의 위반한 사항을 구체적으로 말해야 하지 않을까? 디지털 교과서의 컨텐츠 포맷에 특정 업체의 독점 포맷을 사용한 정책적 방향에 대해 비판할 수는 있어도 (나 역시 반대하지만), 역시 GPL 위반은 아니다.
2009년 2월 18일 수요일
Cubrid + unixODBC + OO.org
아직도 헝가리언 스타일이 유행하고 있는 ODBC 관련 코드를 보기 싫었지만 대충 동작:
여담이지만, 큐브리드는 현재 코드로는 패키징 불가능이다. 다운로드에 있는 RPM 패키지도 만들어진 모양으로 볼 때 (root 권한으로 셸 들어가서 실행하는 대모험을 할 게 아니라면) 분명히 안 돌아간다. 현재와 같이 한 폴더에 라이브러리, 클라이언트, 서버, 데이터까지 몰아 넣고 서로 엮여 있는 현재의 모양으로는 SE가 고객의 전화를 받고 출동해서 깔아 주는 경우라면 상관없을 지 몰라도, 패키징과 시스템 연동 측면에서는 환영받지 못한다. DB 포맷, 통신 프로토콜, 라이브러리 인터페이스 모두 버전 사이의 호환성을 보장하지 않고 있기 때문에 인터페이스를 만들기도 쉽지 않다. 더 문제가 되는 라이선스 충돌 문제를 해결했으니 다행이지만 큐브리드 프로젝트는 갈 길이 멀다.
여담이지만, 큐브리드는 현재 코드로는 패키징 불가능이다. 다운로드에 있는 RPM 패키지도 만들어진 모양으로 볼 때 (root 권한으로 셸 들어가서 실행하는 대모험을 할 게 아니라면) 분명히 안 돌아간다. 현재와 같이 한 폴더에 라이브러리, 클라이언트, 서버, 데이터까지 몰아 넣고 서로 엮여 있는 현재의 모양으로는 SE가 고객의 전화를 받고 출동해서 깔아 주는 경우라면 상관없을 지 몰라도, 패키징과 시스템 연동 측면에서는 환영받지 못한다. DB 포맷, 통신 프로토콜, 라이브러리 인터페이스 모두 버전 사이의 호환성을 보장하지 않고 있기 때문에 인터페이스를 만들기도 쉽지 않다. 더 문제가 되는 라이선스 충돌 문제를 해결했으니 다행이지만 큐브리드 프로젝트는 갈 길이 멀다.
2009년 2월 10일 화요일
티스토리 탈출 예정
제한적 본인 확인제 등 규제로 인한 제약도 거리끼는 부분이다. 특별히 정치적인 입장을 드러내지도 않고, 불법이나 명예훼손에 관련되지도 않기 때문에 거리낄 일은 없지만, 귀찮고 기분 나쁜 일은 누구에게든 생길 수 있는 일이므로 벗어나고자 한다. 정책적 방향이 바뀌지 않는 한 어디로 탈출하더라도 이 제도는 계속 확대되겠지만 되는 데까지 버텨 본다.
진짜 불편한 부분은, 대형 포털의 고질적인 문제로, 아무리 문제점을 피드백해도 전달이 안 된다. 고객 센터는 매우 친절하게 대응했지만 사용법을 헤매는 고객을 돕는 방법만 교육 받았지 문제점 해결을 전달하는 교육은 받지 못한 모양이다. 나는 형식적인 친절함을 원하는 게 아니라 문제의 실질적인 해결을 원한다. 아무리 구체적으로 버그의 원인을 설명해도 잘 모르겠으면 "전화 주시면 해결해 드리겠습니다"라고 결론이 나면서 단답형으로 처리가 끝나는 상황은 답답하기 짝이 없다. 물론 블로그 사이트가 프리소프트웨어도 아니고 피드백을 하면서 고쳐 쓸 생각을 하는 게 잘못일지도 모르겠지만 답답한 상황은 벗어나고 싶다.
피드백이 안 된다는 것과 더불어 변화가 느린 것도 피로하게 느껴진다. 문제점 중에는 태터툴즈/텍스트큐브에 이미 반영된 사항도 있었기 때문에 더 그렇게 느껴진다. 만약 내가 티스토리 개발 방향을 결정할 수 있는 사람이었다면, 개발 조직을 대형 포털의 체계 속에 집어 넣어 격리시키는 게 아니라, 태터툴즈/텍스트큐브 오픈소스 프로젝트에 적극적으로 참여함으로써 문제를 해결하려 했을 것이다. 지금은 갈라선 지 오래 되어서 너무 늦었을까?
어쨌든 TNC가 맨 처음 티스토리를 시작할 때 내세운 티스토리의 장점은 그것이었다. 회사가 사용자를 컨트롤하지 않는 블로그. 별도의 도메인을 허락하고, 페이지 내용의 다양한 커스터마이즈를 허락하고, 티스토리를 떠나더라도 백업이 쉽다. 새삼 이러한 방향의 결정은 옳았다는 걸 느낀다. 백업 파일 포맷이 그 사이에 달라졌다는 이야기도 있지만 (1) 불가능하지는 않겠지..
진짜 불편한 부분은, 대형 포털의 고질적인 문제로, 아무리 문제점을 피드백해도 전달이 안 된다. 고객 센터는 매우 친절하게 대응했지만 사용법을 헤매는 고객을 돕는 방법만 교육 받았지 문제점 해결을 전달하는 교육은 받지 못한 모양이다. 나는 형식적인 친절함을 원하는 게 아니라 문제의 실질적인 해결을 원한다. 아무리 구체적으로 버그의 원인을 설명해도 잘 모르겠으면 "전화 주시면 해결해 드리겠습니다"라고 결론이 나면서 단답형으로 처리가 끝나는 상황은 답답하기 짝이 없다. 물론 블로그 사이트가 프리소프트웨어도 아니고 피드백을 하면서 고쳐 쓸 생각을 하는 게 잘못일지도 모르겠지만 답답한 상황은 벗어나고 싶다.
피드백이 안 된다는 것과 더불어 변화가 느린 것도 피로하게 느껴진다. 문제점 중에는 태터툴즈/텍스트큐브에 이미 반영된 사항도 있었기 때문에 더 그렇게 느껴진다. 만약 내가 티스토리 개발 방향을 결정할 수 있는 사람이었다면, 개발 조직을 대형 포털의 체계 속에 집어 넣어 격리시키는 게 아니라, 태터툴즈/텍스트큐브 오픈소스 프로젝트에 적극적으로 참여함으로써 문제를 해결하려 했을 것이다. 지금은 갈라선 지 오래 되어서 너무 늦었을까?
어쨌든 TNC가 맨 처음 티스토리를 시작할 때 내세운 티스토리의 장점은 그것이었다. 회사가 사용자를 컨트롤하지 않는 블로그. 별도의 도메인을 허락하고, 페이지 내용의 다양한 커스터마이즈를 허락하고, 티스토리를 떠나더라도 백업이 쉽다. 새삼 이러한 방향의 결정은 옳았다는 걸 느낀다. 백업 파일 포맷이 그 사이에 달라졌다는 이야기도 있지만 (1) 불가능하지는 않겠지..
나눔고딕코딩 변환한 "무난" fontforge 스크립트
역시 DejaVu 만한 게 없다. DejaVu Sans Mono와 폭을 맞추자. 방법은 다른 곳에 많이 설명되어 있으니 생략하고, 그 과정을 앞으로도 써먹을 수 있도록 스크립트로 만든다.
http://gist.github.com/60908
실제로 Vera / DejaVu 호환을 목적으로 만들어진 글꼴도 있는데 Arundina 타이 글꼴이 그 경우이다. 한글 글꼴보다야 만드는 난이도는 낮지만 Vera / DejaVu에 호환되도록 만들어졌다. 이왕이면 기존 글꼴들과 잘 어울리게 만든 글꼴이 있으면 fontconfig에서 사용할 시스템 글꼴로는 이상적인 형태가 아닐까? (역시 디자이너들은 버럭하겠지만)
http://gist.github.com/60908
$ fontforge -script nanum2munan.pe NanumGothicCoding-Bold.ttfMunan은 OFL에 따라 이름을 바꾼 것. :-) 폭이 바뀌면서 자간이 늘어나 버렸기 때문에 이상적인 형태는 아니지만 그렇다고 스케일하면 힌팅이 망가질게 거의 확실하다.
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
실제로 Vera / DejaVu 호환을 목적으로 만들어진 글꼴도 있는데 Arundina 타이 글꼴이 그 경우이다. 한글 글꼴보다야 만드는 난이도는 낮지만 Vera / DejaVu에 호환되도록 만들어졌다. 이왕이면 기존 글꼴들과 잘 어울리게 만든 글꼴이 있으면 fontconfig에서 사용할 시스템 글꼴로는 이상적인 형태가 아닐까? (역시 디자이너들은 버럭하겠지만)
2009년 1월 31일 토요일
현재 유닉스 스타일 파일시스템의 의미는
리눅스에서 많이 사용하고 있는 File Hierachy Standard 는 전통적으로 유닉스에서 사용되던 표준 파일 시스템을 명백히 표준으로 정의한 것이다. 유닉스나 리눅스 사용자라면 익숙하다 못해 친근하기까지 한 /lib, /bin, /sbin, /usr/bin, /usr/share, /usr/lib 따위의 구조는 영원히 없어지지 않는 성역이라고 생각하기 쉽지만, 이제 근본적으로 바뀔 때도 되지 않았을까? 과거의 유닉스 플랫폼의 사정이 오늘날에도 적용이 될까?
유닉스 파일 시스템의 구조는 몇 가지 목적을 가지고 만들어졌다.
정말 공유하는 사람이 있나요?
큰 목적은 "파일 시스템의 공유 가능"이다. 부팅에 필요한 파일은 컴퓨터마다 필요하지만 /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 문서에 따르면:
바꿀 필요가 없으니까?
굳이 전통적으로 잘 써 왔고 각종 툴이 잘 지원하는 지금의 파일 시스템 구조를 바꿀 필요가 있을까?
일단 현재의 문제는, 소프트웨어 바이너리 패키지의 유연성이 떨어진다. 현재 조금 복잡도가 높은 리눅스 소프트웨어들은 빌드타임에 데이터가 들어 있는 디렉터리가 보통 하드 코딩되어 있다. RPM 패키지의 경우 /usr, /usr/local을 선택할 수 있는 relocatable 패키지를 만들 수 있는 기능이 있지만 이렇게 경로를 하드 코딩하는 애플리케이션들은 relocatable하게 만들기 어렵다. 현재의 파일 시스템에서는 바이너리 패키지만으로 같은 애플리케이션의 여러 버전을 동시에 설치하거나 사용자에 따라 다른 애플리케이션을 설치한다거나 하는 유연성이 없다.
애플리케이션별로 별도의 경로로 설치하면 명령어 실행 경로라든지 ($PATH), 맨페이지, 폰트처럼 한 프로그램이 사용하는 데이터를 여러 패키지에서 설치하는 경우에 문제가 생기지만, 해결 방법은 있다. 한 디렉토리 안에 파일을 몰아 넣지 않더라도 파일시스템의 기능을 통해 여러 경로의 내용들을 한 곳으로 자동으로 합치는 기능이 있다. (이름이 생각이 안 나서 검색 불가...)
유닉스 파일 시스템의 구조는 몇 가지 목적을 가지고 만들어졌다.
- 부팅과 최소한의 관리에 필요한 파일 (/), 시스템 설치 파일 (/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), 맨페이지, 폰트처럼 한 프로그램이 사용하는 데이터를 여러 패키지에서 설치하는 경우에 문제가 생기지만, 해결 방법은 있다. 한 디렉토리 안에 파일을 몰아 넣지 않더라도 파일시스템의 기능을 통해 여러 경로의 내용들을 한 곳으로 자동으로 합치는 기능이 있다. (이름이 생각이 안 나서 검색 불가...)
피드 구독하기:
글 (Atom)