리눅스에서 왜 유튜브 제목의 초중종성이 분리되는가

리눅스에서 몇몇 유튜브 영상을 보면 제목이 요상하게 초/중/종성이 분리되어 있는 걸 볼 수 있다.

마침 이 NHN NEXT 페이지가 매우 인상적인데, 리눅스에서는 "NHN NEXT 2014학년도 2차 모집 안내동영상_서류제출안내" 영상의 제목이 끝의 "류제출안내"만 "ㄹㅠㅈㅔㅊㅜㄹㅇㅏㄴㄴㅐ"와 같이 보인다.

http://www.youtube.com/user/NHNNEXT

아마도 이 영상을 올리신 분은, 맥에서 "류제출안내"를 파일이름에서 복사해서 붙여넣기 하셨을 것이다.

근본 원인: 맥 오에스의 파일시스템

문제의 시작은 맥 오에스 파일시스템이 내부적으로 유니코드 인코딩을 NFD로 (참고: 유니코드 정규화) 사용하기 때문이다. 맥 오에스의 이 정책은 한글 뿐만 아니라 독일어 umlaut나 프랑스어 cedilla 같은 각종 액센트도 마찬가지로 적용된다. 한글의 경우 NFD는 한글 음절 코드가 U+1100의 한글 자모 코드로 변환되어 초중종성 코드로 나뉘게 된다.

이 문제는 유튜브 외에 여러 곳에서도 드러난다. 네트워크 파일시스템에서 한글 파일이름의 인코딩을 바꿔서 저장한다거나, 배포한 압축 파일의 파일이름도 초중종성이 분리되어 있거나, SVN으로 받은 한글 파일이름을 맥 방식으로 바꿔서 커밋한다든지, 구글 드라이브를 맥에서 싱크하니까 모든 한글 파일이름의 초중성을 분리한다든지 따위의 해프닝이다.

애플의 이러한 정책은 기술적 취지는 이해할 수 있다. 유니코드에서 같은 내용을 여러가지 방법으로 표현할 수 있는 문제가 있기 때문에, 전부 NFD로 바꾸면 한 가지 방법으로 전부 커버할 수 있으면서 유일성을 보장할 수 있다. 하지만 파일 이름이 파일 이름이 아닌 곳에서 드러난다는 건 문제이다. NFD가 틀린 인코딩은 아니다. 하지만 맞다 틀리다의 문제가 아니라, 일반적으로 많이 쓰이는 인코딩을 사용하는 게 상식적이지 않을까.

나눔 글꼴의 기능 미비

이 경우에도 결국 한 음절로 표시하면 되지 않느냐라고 물을 수 있는데, 리눅스의 글꼴이 그런 기능을 지원하면 가능하다. 하지만 현재 대부분 리눅스 배포판에서 사용하고 있는 나눔 글꼴에는 그런 기능이 들어 있지 않다. 이런 나눔글꼴 수정도 작업 중인 게 있으니 앞으로는 이런 기능의 글꼴이 일반적이 될 수도 있지 않을까.

Pango의 버그

윈도우나 맥용 글꼴이라고 해서 한글 자모 코드를 잘 지원하는 건 아니다. 그러면 왜 리눅스에서 유독 분리되어 보일까. 보통 현대 음절의 경우는 글꼴을 사용하기 전에 렌더링 엔진이 조합해 주기 때문이다. 별다른 기능이 아니기 때문에, gtk에서 사용하는 렌더러인 pango의 한글 렌더러를 처음 작성할 때부터 들어 있었는데 무슨 이유에서인가 망가져 있다. 다음 버그로 보고된 상태.

https://bugzilla.gnome.org/show_bug.cgi?id=705727

구글이 좀 고쳐주지

사실 가장 쉬운 해결 방법은 유튜브에서 자동으로 바로잡아 주는 것. 굳이 사용자가 올린 형태를 유지할 필요도 없을 것 같고, 어차피 내부적으로 검색도 하려면 변환하는 게 큰 문제는 아닐 것이다. 실제로 dropbox같은 경우 처리를 해 주는지 맥과 다른 OS 사이에서 한글 파일이름 공유에 문제가 없다.  하지만 구글에 뭐 고쳐달라고 요청한다고 고쳐주는 것 만큼 어려운 건 없으니...



위의 넷 중에 어떤 방법이든 바로잡으면 제대로 동작한다.

새 hwp 리스트

libhwp 그룹스마저 폭파됐기 때문에, HWP 그룹스를 새로 만듭니다. 앞으로 어떻게 될지는 모르겠지만 언제나처럼 가볍게 시작합니다.

https://groups.google.com/forum/#!forum/hwp-foss


libhwp 리스트 복구에 대해

제 메일에 있는 내용은 다음에 mbox 포맷으로 올려놨습니다.

https://sites.google.com/site/libhwprestored/home

- 제가 가입한 2010년 10월 22일부터 메일은 다 있지만 그 전에는 없습니다. 거의 만들어지자 마자 제가 가입했기 때문에 누락된 메일은 몇 개 안 될 겁니다. 누락된 부분도 혹시 메일로 보관 중이시거나 찾을 수 있으신 분은 알려 주세요.

- 가공해서 보기 좋은 모양으로 웹에 올려 놓는 것도 과제입니다. 아이디어 있으면 주세요.


2013년 12월 21일 업데이트: 아카이브 완성. 지난 토론 내용, 또는 지난 플레임을 보고 싶으시면:

https://googledrive.com/host/0BzxIVzS0OjQTSEpScE5lcmRhajA/threads.html

libhwp woes

libhwp 개발자께서 github 계정을 삭제하셨습니다. 하필이면 제가 evince-hwp에 데비안 패키징과 관련된 이슈를 문의했을 때, 굉장히 신경질적으로 반응하시면서 프로젝트를 삭제하겠다고 선언하셨는데요.

그 분의 선택을 존중합니다. 그리고 최근에 보기 싫은 일 https://plus.google.com/+ChangwooRyu/posts/h7eq6KqhYMW 때문에 기분이 안 좋은 것도 십분 이해합니다. 하지만 저와 해당 이슈에 대한 반응은 이해할 수 없었습니다. 패키징을 위해 업스트림 저자와 의견을 교환하고 하는 일은 일상적인 일이고, 이슈도 대단치 않은 빌드 변경이었습니다. 이슈 내용이나 이런 피드백 활동 자체가 마음에 안 드신다면 어쩔 수 없지만, 이슈 내용에 대해서 불만을 터뜨리는 것도 아니고 지금까지 프로젝트 관련된 각종 불만이나 개인 사정까지 이슈 페이지에서 폭발하는 건 상식적으로 이해가 가지 않았습니다.

다음에 어떤 일을 하시든 부디 마음을 가볍게 갖고 하셨으면 좋겠습니다.

관련 프로젝트도 현재 접근할 수 없는데 다행히 최근 커밋까지 받았기 때문에 제 clone에 푸시해 놨습니다. 데비안 패키징도 계속됩니다.

https://github.com/changwoo/libhwp
https://github.com/changwoo/evince-hwp

NIPA "유망 공개SW 프로젝트 목록" 중에서

공개SW 가이드/보고서 - [2013] 유망 공개SW 프로젝트 목록(오픈프론티어)

http://www.oss.kr/oss_notice/oss_repository12/103649

• 한국 사람이 운영하는 프로젝트가 이상하게 많다.
• nodejs 관련 프로젝트도 전체에서 비중이 높다
• "3년간 커밋 수 증가"라는 기준을 통해 커뮤니티 성장성을 평가하려고 시도한 것 같은데 올바른 평가 기준이 되지 못한다. 대략 20%를 넘어서면 성장성이 높다고 평가하는 것 같은데, 숫자가 편차가 지나치게 큰 데다 이렇게 평가한 성장성과 "뜨는 프로젝트"와는 거리가 멀다. 
• 수없이 많은 프로젝트 중에 186개의 프로젝트를 리스트업하는 게 의미가 있는지 의문이다. "오픈 프론티어" 사업의 평가 기준으로 삼으려는 생각인지 모르겠으나, 제대로 된 오픈소스 개발자라면 스스로 과제를 선정하고 중요성을 어필하고 그걸 제3자가 검토하는 과정을 통해 평가돼야 하지, 현실을 제대로 반영하기 힘든 제한된 리스트를 통해 중요성이 과대 또는 과소 평가돼서는 안 될 것이다. 

 
 

삼성 exFAT 드라이버 유출과 공개 사건에 대해

삼성의 exFAT 드라이버 유출과 관련해, 엉뚱한 삼성 비난 또는 삼성 옹호 얘기가 있길래 실제 코드를 보고 파악할 수 있는 쟁점을 지적해 보고자 한다. 일단 사건의 개요는 넘어가고,

관련 기사 http://www.etnews.com/news/computing/solution/2817944_1476.html

유출된 코드 https://github.com/dorimanx/exfat-nofuse

공개된 코드 http://opensource.samsung.com/reception/receptionSub.do?method=sub&sub=F&searchValue=exfat


- 위 기사의 후반부의 특허 논란 얘기는 틀린 내용이다. 특허는 논란의 여지가 없다. 삼성과 MS는 2011년 크로스 라이선싱 계약을 맺은 상태이므로 삼성 제품에 사용하는 건 삼성의 정당한 권리. 그리고 특허 시스템을 모르는 사람들이 특허가 공개되도 괜찮으냐고 의문을 품는데, 특허는 원래 공개된 거고 특허와 소스 코드의 라이선스는 별개의 문제이다.

- 유출된 코드의 GPL 위반이 발견된 상황에서 삼성의 선택은 두 가지가 있었을 것이다. 첫 번째는 이 코드는 GPL과 별개의 작업이다라고 주장하면서 논란을 확대하는 것이고, 또 하나는 그냥 소스 코드를 공개해 버리고 논란을 종식시키는 것. 이 중에서 후자를 선택한 것은 잘 한 일이었다.

- 하지만 생각해 보면 삼성은 그렇게 선택할 수밖에 없었다. 리눅스 커널 드라이버가 GPL이냐는 떡밥은 참 전통이 깊고, 애매한 상황 아니냐고 논란이 생길 수도 있는데, 적어도 이번 사건은 지금까지 알려진  애매한 상황이 아니라 명확한 GPL 위반 상황이었다. 이 드라이버는 처음부터 리눅스를 위해 작성된 드라이버이므로 GPL v2 section 3에 정확히 걸린다. 또 유출되고 공개된 코드를 실제로 보면 기존 FAT 드라이버 코드의 많은 부분을 복사 붙여넣기 한 게 너무 명확했다. 따라서 이 드라이버는 명백한 GPL 코드의 파생물이었다. 링크가 되니 안 되니 논쟁의 문제가 아니다. 즉 애초부터 이 드라이버의 소스 코드는 삼성이 GPL로 릴리스했어야 했다. 그게 유출이라는 또 다른 불법적인 경로를 통해 들통이 난 것이다.

- 한편 많은 뉴스 기사를 보면 GPL-only symbol을 썼다고는 하는데 ("Samsung was shipping this closed-source exFAT driver on a tablet yet they were relying upon GPL-only symbols") 유출된 버전과 공개된 버전이 차이가 있다. 실제 공개된 드라이버에는 GPL 심볼이 사용되지 않아서 이 부분은 사실인지 의심스럽다. 유출된 코드에서는 GPL 심볼을 사용한 부분이 있으나 나중에 공개된 소스나 제품에 포함되어 있는 바이너리에는 그런 흔적이 전혀 없기 때문에, 유출된 버전이 나중에 수정되면서 추가된 부분일 가능성이 높다. 게다가 GPL 심볼을 사용하는 커널 드라이버가 GPL 라이선스를 안 붙이게 우회하기도 쉽지 않고, 그 과정에서 법적 논란이 있음을 쉽게 인식할 수 있는데 악의적으로 감췄을 것 같지도 않다.

- 삼성의 오픈 소스 정책이 무엇이든, 감출 수 있으면 감추는 게 기본 방침이라고 하더라도, 이번 부분은 감출 수 없고 공개했어야 하는 부분을 감춰 버렸던 것은 명백하다. 오픈소스 관리에 놓친 부분이 생긴 건 사실이다.

사운드그래프 아이몬 리모콘 드라이버의 기억

최근 머지된 리눅스 드라이버 중에 하나가 리모콘 드라이버가 있다. 기존에 LIRC에서 배포되었었던 드라이버가 하나씩 driver/media/rc 아래에 머지되고 있다. 그 중에 한 staging 드라이버 코드의 주석에 잠깐 내 이름이 언급된 걸 보고 생각나는 오래전 이야기.

https://github.com/torvalds/linux/blob/master/drivers/staging/media/lirc/lirc_imon.c#L640

10여년 전, 기억은 나지 않지만 무슨 바람이 불었는지 USB용 IR 리시버와 리모콘이 세트인 제품을 하나 구입했었다. 한국 회사 사운드그래프에서 만든 제품이길래 메일로 리눅스 드라이버 좀 작성해 볼테니 IR 코드랑 리시버 정보 좀 알려달라고 요청했더니 달라는 정보는 안 주고 "..,한번 봅시다 전화..."라는 답을 듣고 황당했던 기억. 답메일로 노땡큐를 날린 다음, USB 인터럽트 데이터를 덤프해 가면서 리눅스 input 드라이버를 작성. 다행히 제조사의 도움 없이 작성될 수 있을 만큼 하드웨어 인터페이스는 간단했다. 별도의 초기화가 없어도 가만히 놔두면 IR 신호를 인터럽트로 알려주는 몹시 단순한 녀석. 단순하다 못해 입력이 없을 때도 인터럽트를 시도 때도 없이 날리는 비효율적인 불량 하드웨어였다.

지금 staging에 들어 있는 lirc 드라이버는 그 때 작성한 드라이버를 보고 다른 사람이 lirc용이 낫지 않겠느냐고 메일을 보냈었고 결국 직접 리시버를 작성한 버전. 지금 생각해 보면 당시에는 USB 리시버 드라이버와 리모콘 드라이버가 합쳐진 내 코드는 방향이 잘못되었고, LIRC 드라이버가 올바른 방향이었다. 그리고 필요없어진 내 코드는 역사 속으로.

http://imonremote.cvs.sourceforge.net/viewvc/imonremote/imon-driver/imon_input.c?revision=1.1&view=markup&pathrev=MAIN

10년이 지난 지금도 이 리모콘 제품은 팔리고 있고, HTPC용 리모콘으로 많이 쓰이는 streamzap 대신 저가형 대안으로 꽤 쓰이는 걸 보면 내가 조금은 기여하지 않았나 싶다. 사운드그래프가 좀 더 협조적이었으면 더 좋은 기억으로 남았을텐데.

virtualbox와 키보드보안

virtualbox에서 돌아가는 윈도우에서 뱅킹 플러그인을 깔면서 virtualbox가 죽는 현상은 많이 보았을 겁니다. 하지만 키보드 보안 제작한 개발자가 일부러 가상머신을 사용하면 무용지물이니 엿먹이려고 죽이는 건 아닙니다. 모든 일에 사람의 의도가 있다면 참 얼마나 설명하기 편하겠냐마는.

PC의 PS/2 키보드의 하드웨어는 수십년전 PC 초창기의 8042 칩셋이 하는 일과 별로 다르지 않습니다. 단지 지금은 메인보드 칩셋에 원칩으로 올라가 있지요. 키보드 보안 플러그인은 암호화라는 이유로 키 시퀀스에 쓰레기 정보를 넣게 되는데 그 과정에서 이 칩셋의 주소를 직접 접근합니다. (USB 키보드가 많이 퍼진 지금에 이게 무슨 의미가 있는지 싶지만.) 문제는 이 키보드 보안 플러그인은 오늘날의 주요 OS가 전혀 사용하지 않는 하드웨어 주소에 접근한다는 것이지요. 그러므로 가상 머신에서 생각하지 못한 코너 케이스가 발생합니다. 정확히 잡으려면 제대로 디버깅을 해 봐야 겠지만 virtualbox 소스에서 src/VBox/Devices/Input/DevPS2.cpp

vmware는 뭔가 이런 주소에 접근하는 것 마저 하드웨어와 똑같이 동작하도록, 최소한 문제는 없도록 작성된 모양입니다.

"오픈소스 SW 개발 지원 사업" 개인 지원에 대해

http://www.dt.co.kr/contents.html?article_no=2013032002011160600006
("정부 오픈소스 SW 개발 지원, 기업 중심서 개인으로 확대")

http://www.nipa.kr/biz/noticeView.it?bizId=00039&boardId=noti&boardNo=43&menuNo=18&page=1

기존에 기업이나 대학 연구실만 배불리고 실질적인 성과가 없는 문제를 인식하고 해결하려는 NIPA의 노력은 인정할 만 하지만, 여전히 개인이 지원하기는 무리가 있다.

일단 절대적으로 액수가 작다. 개인이 5천만원이라고 써 있지만 세부 항목을 들여다 보면 인건비가 월 150만원으로 제한되어 있다. 또 개인이 지원하려면 다른 직업이 없거나 직업이 있으면 대표이사 승인이 필요하다. 1년 예산이라면 5천만원 중에 나머지를 다른  비용 따위로 소모해야 하는데 개인이 하는 프로젝트에서 인건비만큼의 액수를 다른 비용에 소모할 일이 있을지 의문이다. 특별히 장비나 비용이 필요한 종류의 프로젝트로 지나치게 제한되거나, 아니면 필요없는 비용을 무분별하게 소모하게 되지 않을까. 이런 과제는 인건비 90%로 예산을 짜도 되는 일이었다.

또한 이 구조로는 대형 프로젝트에 적극적으로 참여하는 사람보다는 개인이 거의 혼자 운영하는 독립 프로젝트만 요건에 부합하게 된다. 과거의 KIPA에서 NIPA로 이어지는 오픈소스 지원 프로그램의 결과를 되짚어보면 과제를 위해 잠깐 만들어졌다가 방치되는 초보적인 sf.net / github 프로젝트만 양산하게 될 가능성이 높다.

해법을 어떻게 찾아야 할까. 사업이 공공 과제의 형식을 가지고 있는 한 문제는 해결하기 힘들어 보인다. 세금으로 조성한 자금의 사용 내역을 철저히 남기는 건 중요한 일이지만, 개개인이 만족시키기 힘든 조건과 절차 때문에 지원이 필요한 전문가보다는 과제 전문가들이 이 자금을 가져가게 된다. 또 공공과제처럼 제안서에 쓴대로 오랜 기간 동안에 하는 일과 참여 인원이 고정되어 있는 방식은 바람직한 오픈소스 운영 방식도 아니다.

이러한 프로젝트를 직접 진행하는 조직을 주도적으로 만들고 그 조직이 개발자를 직접 고용하는 우산 역할을 하는 게 가능한 방법이다. 하지만 이렇게 프로젝트를 직접 진행하게 되면, 책임 소재를 유난히 따지는 공공의 특성상 실패할 때 책임도 직접 지게 되어 실현되기는 어려워 보인다. 또 실현이 되더라도 제대로 필요한 프로젝트를 진행하고 개발자를 채용하고 유지할 수 있을지도 의문이고 말이다.


곁다리지만, 만약 공공이 주도하는 프로젝트의 주제가 마땅치 않다면, 다음 기고글에서 언급된 것처럼 전자정부프레임워크를 비롯한 공공정보화 사업이 공공 주도 프로젝트의 좋은 주제가 될 수 있을 것이다.

http://www.zdnet.co.kr/news/news_view.asp?artice_id=20121127155952("공개SW 살리려면 '커미터' 육성“…어떻게?")

이스트소프트 리눅스용 unegg에 대해

리눅스용 unegg 소스코드가 제작년부터 배포되고 있습니다. ( http://www.altools.co.kr/Product/ALZip_Intro.aspx )

하지만 받아보시면 예상하신 것과 같이, 또는 리눅스용 소스 코드에 어울리지 않게 제약이 붙어 있습니다. 첫째는 비상업적 목적으로만 사용과 배포가 허락된다는 것, 또 하나는 코드의 수정이 금지되어 있다는 점입니다. 특히  "EGG 패키지에 포함된 압축 알고리즘은 수정할 수 없으며 EGG 포맷 및 압축 알고리즘을 개발하는 목적으로는 사용할 수 없습니다." 이렇게 포맷 구현할 수 없다고 강조되어 있습니다. 문서에 보면 리틀 엔디안에서만 동작한다는 언급도 있습니다.

이스트소프트에서 새로 만든 EGG 포맷은 포맷을 공개했다고 알려진 포맷입니다.  ( http://www.altools.co.kr/Product/alzip_egg.aspx ) 하지만 공개된 이 포맷 문서 역시 같은 라이선스로 배포됩니다. 비상업적으로 사용할 수 있고, 포맷을 구현하는데 사용할 수 없는 라이선스인 것이죠. 포맷 구현을 안 할 거면 대체 이 문서를 왜 본다고 생각하는 걸까요?

사실 리눅스에서 alz까지는 잘 지원하는 편이었습니다. 호환 프로그램인 unalz가 거의 모든 배포판에 들어가 있었고, file-roller와 연동하는 기능이 들어가서 (https://bugzilla.gnome.org/show_bug.cgi?id=521324) 그놈 데스크톱에서는 노틸러스(파일)에서 누르면 바로 보이고 풀 수 있었죠. 이스트소프트의 힘을 빌리지 않고 아마추어들의 힘만으로 만든 노력의 산물이었습니다. 하지만 기본적으로 큰 잇점이 없는 새로운 EGG 포맷을 원하지도 않고 압축을 푸는 일에 위와 같은 라이선스 제약이 있는데 배포판이나 데스크톱 통합에 노력을 기울이기는 어렵습니다. 배포판에 들어가기도 힘들겠지요.

리눅스용 unegg, 정말 아쉬울 때만 받아서 컴파일해 사용하시고, 웬만하면 egg가 아닌 자료를 구하시고 egg를 쓰지 말라고 주위에 알리시기를 바랍니다.