XLA를 소개합니다.

최근 업무 관련해서 XLA를 알게 되었는데, 재밌는 프로젝트인데 반해 관련된 자료를 찾는게 쉽지 않길래 한번 소개를 해보면 좋을 것 같다는 생각이 들었습니다.

우선 XLA (Accelerated Linear Algebra)는 Tensorflow의 서브 프로젝트로 그래프 연산의 최적화 / 바이너리 사이즈의 최소화 등을 목적으로 하는 컴파일러입니다.

Continue reading XLA를 소개합니다.

slacker 기반 slackbot 만들기

재밌어보이길래 python으로 간단한 슬랙봇을 만들어볼까 하고 알아봤더니 slackbot이란 모듈을 사용하면 슬랙봇을 쉽게 만들 수 있을것 같아서 슬랙봇을 만들어봤다.

그런데 파이썬 프로세스는 멀쩡하게 살아있지만 하루 정도가 지나면 봇이 disconnected 상태로 바뀌는 문제가 지속적으로 발생하는 문제가 있었다. 관련해서 예제 코드들을 찾아봐도 별다른 부분이 없길래 며칠 동안 디버깅을 하면서 문제를 해결해봤다.

우선 인터넷에 떠도는 slacker 기반 echo 봇의 기본 골격은 아래와 같았는데…
Continue reading slacker 기반 slackbot 만들기

지멋대로의 영어를 더 자주 볼 수 있었음 좋겠습니다.

이 글은 More Bad English, Please란 글을 번역한 글입니다. 🙂
약간의 의역과 오역이 있을 수 있으니 양해 바랍니다.

메일링 리스트에서 어색한 영어를 더 많이 볼 수 있었음 좋겠습니다. 그리고 메일링 리스트에서 비영어권 사용자들의 어색한 영어에 대한 사과를 그만 볼 수 있었음 좋겠습니다. 제 2, 3, 4 외국어를 사용해서 대화를 시도해보는 것에 부끄러워하지 마시기 바랍니다. 만약 영어에 대한 두려움/당황감 때문에 비영어권 사람들이 참여하지 못하는 분위기를 만들었다면 그것이 바로 부끄러워해야할 점일 것입니다. 이런 사용자들의 질문이나 공헌들을 통해 FLOSS 프로젝트는 더욱 성공적으로 나아갈 수 있습니다.
오픈소스의 대단함 중 하나는 여러 나라의 사람들이 함께 작업을 한다는 것입니다. 누구나 찾을 수 있는 진정한 “잡탕 냄비”이죠. 오픈소스에 참여하는 사람들 중 공통으로 사용할 수 있는 언어가 영어이다 보니 메일링 리스트에서는 주로 영어를 사용합니다. 하지만 대부분의 경우 영어는 그들의 모국어가 아닙니다. 심지어는 그들이 구사하는 제 2, 3 외국어 조차 아니기도 할 정도이며, FLOSS 메일링 리스트에 참여하는 것이 영어로 글을 작성하는 유일한 경험인 사람들도 있습니다. 그러다보니 다양한 문화적 시각을 가지게 되고, 이들이 구사하는 영어들도 그리 완벽하지는 않습니다.
만약 내가 받는 메일 중 “poor English”에 대한 사과가 포함된 메일 각각에 따라 $1씩을 받았다면, 은퇴 후에도 아주 편안하게 살 수 있을 정도일겁니다. 하지만 이런 사과를 하실 필요는 없습니다. 오히려 더 목소리를 더 크게 내시기 바랍니다. 메일링 리스트에서 어색한 영어 표현을 더 많이 볼 수 있었음 좋겠습니다.
누군가와 생산적인 대화를 하기 위해 들이는 노력에 대해 당황스러워하거나 그 사람을 부끄럽게 생각하는 경우는 없습니다. 정신과 수련의 방(room for improvement)이 있다면 대부분 새로운 언어를 배우거나 자신의 언어 능력을 높이기 위해 지속적인 노력을 할 것입니다.
자신의 언어 능력에 부끄러움을 느끼는 사람들은 아무래도 더 적게 말하곤 합니다. 자신의 말을 못알아들을까봐 두려워 질문을 머금고만 있곤 하죠. 예전에 자신이 전하려고 했던 것이 전해지지 않았던 것이 기억나서 생각을 표현하지 못하기도 합니다. 제가 Novell에 있었을 때 가장 좋았던 것은 세계에 퍼져있는 오픈소스를 사랑하는 사람들을 만나 이야기해볼 수 있었고, 커다란 커뮤니티의 일부가 될 수 있었다는 점입니다. 아쉽게도 제가 만나봤던 사람들 중 많은 사람들이 자신의 영어가 능숙하지 못하다는 이유로 당황했었습니다. 함께 토론에 참여하길 유도했던 많은 공헌자들이 자신이 못알아들을 것을 두려워해서, 자신의 영어 부족한 영어가 부족하다는 이유를 내세우며 토론에 참여하기를 꺼렸습니다.
그저 두려움 뿐이었을 수도 있습니다. 자신의 영어 때문에 걱정이라고 표현했던 사람들 중 많은 사람들의 경우 아주 유창한 영어를 구사하지는 못했지만 우리가 알아듣는데는 별 지장이 없을 정도의 영어를 구사할 수 있었습니다. Even when there is a moderate language barrier, there should be no shame felt or conveyed for someone trying to participate in their non-native language. 누군가가 한 가지 언어 밖에 구사하지 못해서 다른 사람들에게 그 언어를 사용하게 한 경우라면 진정 부끄러워해야할 것입니다.
전 Seth Godin이 쓴 Linchpin을 읽어본 적이 있습니다. Seth는 좋은 일, 예술 등 그들이 할 수 있는 가장 생산적인 일을 하는 것을 막는 두려움에 대해서 아주 강력히 얘기합니다. 제가 생각하기엔 이런 두려움 때문에 사과를 하는게 아닐까 싶네요. 다른 사람들만큼 그 언어로 잘 이야기 하지 못한다는 이유로 거절당할까하는 두려움, 내 말을 못알아듣지 않을까 하는 두려움, 단순히 무시당하지 않을까 하는 두려움 말이죠.
하지만 이런 일은 없습니다 아니 최소한 있어서는 안될 것입니다. 대부분의 커뮤니티에서는 공헌자로써 시간을 써준 것을 가치있게 생각합니다. 그리고 누구나로부터 이야기를 듣기 위해 노력하고 있죠. 누군가 좋은 일을 하고 있거나 배우려 노력하고 있는 상황이라면 그걸 이해하기 위해 약간의 노력을 더 해야한다고 하더라도 누가 신경이나 쓰겠습니까? 가끔은 엉망인 영어에 가려져 있지만 함께 일하고 싶을 똑똑하고 재능있는 공헌자들을 찾을 수 있습니다. 그러니 메일링 리스트에서 엉망인 영어를 더 자주 볼 수 있었음 좋겠습니다. 그리고 아마 그래줄거라 믿습니다. 이 말을 여기저기 퍼트려주세요.

MySQL의 라이센스 모델이 가지는 의미는? MySQL은 결국 죽임을 당할 것인가?

우선 이 글은 The importance of the license model of MySQL or Can MySQL be killed?을 번역한 글임을 밝힙니다.
급하게 번역했기 때문에 오역이 있을 수 있음을 양해 바랍니다. 이하 내용은 번역된 내용입니다.
지난 몇 주간 받았던 공통적인 질문들에 대해 답하기 위해 이 포스트를 남깁니다.
A. MySQL이 없어질까?
1. MySQL을 죽이기 위한 제일 간단한 방법은 라이센스를 더이상 팔지 않거나 그 가격을 굉장히 높게 하는 것입니다.
2. 다른 시나리오는 중요한 부분에 대한 개발 인력을 확 줄여버리는 것입니다. 그러면 사람들은 MySQL의 미래에 대해 의심하기 시작할 것이고 서서히 MySQL을 죽여나갈 것입니다. 특히나 현재의 라이센스가 그대로 있다면 더욱 그럴 것입니다. (MySQL의 코어는 대부분 거대한 커뮤니티가 아닌 SUN의 개발자들을 통해 개발되어왔다는 사실을 기억해야 합니다.)
B. “하지만 누구나 fork할 수 있지 않나?”
누군가 GPL 프로젝트(혹은 그 코드)를 이용해서 fork할 순 있겠지만 그 프로젝트나 코드를 둘러싼 경제적 인프라 스트럭쳐까지는 쉽게 복제할 수 없습니다.
MySQL은 엔드 유져용 애플리케이션이 아니고, 인프라 스트럭쳐 프로젝트는 시스템 스택의 깊은 곳에까지 관여되어 있습니다. 최근 MySQL을 이용해서 혁신을 이뤄냈던 기술적인 파트너들은 대부분 MySQL로부터 라이센스를 받아서 자신의 closed 소스 어플리케이션혹은 (스토리지 엔진 같은) 코드와 MySQL을 조합해서 사용할 수 있었고, 라이센스를 통해 파트너들로부터 받아들이는 직간접적인 수입은 경제 인프라스트럭쳐의 굉장히 큰 부분이었습니다. (이들이 어디서 돈을 벌 수 있는가 정도로 생각하심 될 것 같습니다.)
GPL 프로젝트의 인프라스트럭쳐를 포크하는 것을 통해선 위에서 언급한 파트너쉽 같은 일을 할 수 없고, fork된 프로젝트는 자신들만의 closed 소스 파트와 이 프로젝트를 섞어 사용할 수 없도록 만듭니다. 파트너들이 MySQL코드와 자신들의 코드를 섞어 사용할 수 없게 된다면, 이 파트너들은 MySQL이 아닌 다른 프로젝트를 찾게 될 것이고 결국 MySQL로의 자금 이입이나 MySQL을 둘러싼 기술 혁신은 멈춰버릴 것입니다. 다른 프로젝트들에는 누구나 참여해서 돈을 벌 수 있으니 결국 이런 프로젝트들이 MySQL이 하던 일을 대신하게 되는 것이죠.
MySQL을 위한 기술 지원 회사를 만들 수도 있겠지만 이런 것들만으론 MySQL 유져들이 만족할만큼 MySQL 개발할 수 있는 돈을 충분히 벌 수 없습니다. 그러므로 이런 회사들은 MySQL을 조금 천천히 죽게 만들 뿐 살려낼 수는 없습니다.
오라클처럼 많은 사람들이 일하는 회사에 대항할 경쟁력을 가진 상태로 MySQL을 살아있게 하려면 MySQL을 위해 일하는 사람도 많아야 합니다. 이를 통해 충분한 수입을 얻을 수 없다면 (앞에서 언급했듯이 지원을 통해선 충분한 수입을 얻지 못합니다.) 일부 몇 개 회사들만이 개발에 참여하게 될 것이고, 투자회사에서의 지원도 줄어들게 될 것 입니다. 결국 서비스를 통해서 벌어들이는 돈이 전부가 될 것이지만 이 돈은 그리 큰 규모가 될 수 없습니다.
또한 리차드 스톨만이 언급했던 것처럼 MySQL에선 GPL2만을 사용할 수 있으므로, GPL3 코드와는 결합될 수 없습니다. 이 말은 GPL3를 사용하는 자유 소프트웨어 프로젝트들에서 MySQL을 사용할 수 없다는 것입니다. 하지만 이 문제는 경제적인 문제에 비교하면 대단한 문제라곤 할 수 없습니다.
C. “GPL은 충분히 쓸만한 라이센스인가?”
제 생각에 GPL은 굉장히 훌륭한 라이센스입니다. 이 라이센스는 GPL로 된 프로젝트들을 자유롭게 해주는 동시에 회사들이 풀타임으로 개발에 참여하면서 충분히 돈을 벌 수 있는 가능성도 제공하고 있습니다. 또한 GPL은 이런 회사들이 이 제품을 강력하게 관리할 수 있도록 보장해줍니다. (특히나 그들의 *closed source* 기술 파트너들을 위해) 이게 바로 투자자들이 GPL을 사용하는 회사에게 투자하고 싶어하는 이유라고 할 수 있습니다. 투자자들은 이 제품을 fork하는 것을 통해 이 코드에 대한 권한을 줏어가는게 불가능하다는 사실을 알고 있기 때문이죠.
D. 결론
아마 Sun과 오라클도 이 사실을 알고 있을 겁니다. 이게 바로 Sun이 MySQL을 비싼 가격에 사들였던 이유이고, 오라클이 MySQL을 바보로 만드려는 이유이죠.
MySQL을 fork하기만 하는 정도로 간단한 문제였다면 Sun은 MySQL을 사지 않았을 것이고, 오라클은 MySQL을 포함해서 SUN을 사는 대신 MySQL fork를 만들었을테니까요.

Cairo test…

서체 관련된 샘플 페이지를 만들면서 손에 익숙한 gd를 활용해왔는데, gd의 fontconfig 지원이 미약하다보니 아쉬운 점들이 눈에 보이기 시작했습니다.
가장 큰 예로 굴림체, 바탕체, 나눔고딕_코딩 글꼴 같은 고정폭(정확하게는 dual-width) 서체의 영문/한글 너비가 동일하게 보여지는 문제는 fontconfig의 global advance옵션을 통해 해결할 수 있지만, gd에서는 fontconfig의 옵션을 제대로 활용하지 않고 있기 때문에 이 문제를 해결할 수가 없었습니다.
그런 이유로 fontconfig를 제대로 활용하는 그래픽 API를 찾던 도중 Cairo가 생각났습니다. Cairo는 fdo에서 개발한 그래픽 API로 현재 모질라, Gnome 등에서 활발하게 사용되고 있는데, 의외로 X 없이도 설치가 가능하고, API도 아주 단순해서 제가 활용하려던 용도로 딱이더군요.
Continue reading Cairo test…

공개 서체: 네이버 나눔고딕_코딩

얼마전 네이버에서 고정폭 서체인 ‘나눔고딕_코딩’ 서체를 OFL(Open Font License)로 공개하였고, gd를 이용해서 뽑은 12pt 샘플은 다음과 같습니다.

나눔고딕_코딩 12pt 샘플

gd의 문제로 인하여 영문과 한글의 폭이 동일하게 출력되었는데, 맥이나 윈도우, 리눅스(약간의 설정 필요) 등에서는 영문과 한글의 폭이 2:1 이다보니 서체 이름에서와 동일하게 코딩용으로 사용하기에 딱이겠네요.
* http://dev.naver.com/projects/nanumfont
덧: 서체 이름에 사용된 언더바(‘_’) 때문에 맥에서 약간의 문제가 있었는데, 서체가 업데이트 되면서 이름이 ‘나눔고딕코딩’으로 바뀌었고, 맥에서도 문제 없이 사용할 수 있게 되었습니다.

YUVPlayer 업데이트…

사실 저나 제 주위 사람들 말고는 쓰는 사람이 거의 없는거 같긴 하지만 하여튼 메모리 릭을 일으키는 몇 가지 버그를 잡았습니다.

  1. ::GetDC(hWnd) 후 ::ReleaseDC(hWnd,dc) 를 호출 하지 않아서 생기는 메모리 릭
  2. gdTexImage2D 를 반복 호출해서 생기게 되는 메모리 릭

정확하게 설명하면 위와 같구요. ::GetDC 로 받아온 Device Context 는 “꼭” ::ReleaseDC 를 호출해줘야 한다는 msdn 님의 가르침에 따라, 약간의 코드를 추가해줬습니다.
또한 gdTexImage2D 를 반복해서 호출하면 이전 텍스쳐 데이타가 사용하던 메모리 영역은 해제가 될 줄 알았는데, 실제로는 그렇지가 않네요. 텍스쳐 사이즈가 달라지는 경우엔 glDestroyTexture 후 glGenTexture, glBindTexture, glTexImage2D 를 차례로 호출해줘야 하고, 사이즈가 달라질 필요가 없는 경우라면 gdTexSubImage2D 를 사용하면 된답니다. 어려운 openGL 세상이에요.
자세한 수정 사항은 제 trac 페이지에서 확인하심 될 듯~
http://trac.unfix.net/browser/yuvplayer/win/yuvplayer/OpenGLView.cpp
p.s) trac 이 ajax 를 활용하도록 업데이트 되었네요.

소스 공개: yuvplayer

예전 포스트에서 얘기한 적이 있던 제 yuvplayer 를 svn repository 에 추가했습니다. 관심이 있으신 분은 아래 링크를 따라가보시면 되겠네요.
http://trac.unfix.net/browser/yuvplayer
사실 한 달쯤 전에 올려뒀는데, 제 svn repository 는 저조차 잘 가보질 않기 때문에 아무도 몰랐을거라 생각합니다;; 흐흣~ Mac 용 버젼도 있는데, 이건 아직 넣고 싶은 기능들 중 구현을 안한 것들이 많아서 추가해두지 않았습니다.
visual studio 2005 기반으로 작업하다보니 프로젝트 파일등이 모두 vs2005 용이네요. 하여튼 uyuv, yuv444, yuv422, yuv420 등으로 된 파일을 플레이할 수 있고, 마우스 오른쪽 버튼을 누른 후 현재 프레임을 다른 포멧으로 저장하는 것도 가능합니다.
관련 포스트:
mac 버젼 – http://b.mytears.org/2007/06/541
windows 버젼 – http://b.mytears.org/2007/06/544