'약간의 리눅스관련 고찰'에 해당되는 글 35건

2017년 4월 Wine 2.6버전이 개발 버전으로 나왔습니다.

물론 안정 버전은 2.0이지만 Wine의 특성상 안정 버전과 함께 개발 버전을 이용하기 때문에 버전업 속도가 굉장히 빨라졌다는 인상입니다.

사실 Wine은 1.0이 되기까지 10년정도 걸린 장기 프로젝트입니다. 0.99.1~0.99.xx가 계속 되면서 한동안 0.99.infinite(beta) 란 별명까지 얻었습니다. 물론 Wine1.0이 나오고 당시의 주류OS였던 WindowsXP의 호환을 어느 정도 확보하면서 리눅스에서 윈도용 프로그램을 그럭저럭 실행할 수 있게 되었습니다.(특히 Microsoft Office는 우선순위로 지원하는 프로그램이었습니다.)

그 때가 2008년이었습니다. 근 10년만에 2.0이 나오게 된 것입니다.

2008년 7월이 Wine1.0이 드디어 Beta딱지를 떼고 출시하게 되었다. 물론 이때도 문제는 많았지만.

당시의 Wine버전 정책은 다음과 같았습니다.

1.0.x = 안정버전

1.1.x = 개발버전

1.2.x = 안정버전

1.3.x = 개발버전

1.4.x = 안정버전

1.5.x = 개발버전

1.6.x = 안정버전

1.7.x = 개발버전

1.8.x = 안정버전

1.9.x = 개발버전

2.x = 안정버전

자세히 보시면 안정 버전은 1.짝수 이고 개발 버전은 1.홀수 형태였습니다. 그러다가 2.0이 나오게 되면서 현재와 같이 바뀌게 되었습니다. 솔직히 저때는 버전이 좀 지저분하게 올라가곤 했거든요. (1.1.35 대충 이런 식으로...)

지금은 조금 바뀌어서

2.0 = 안정버전

2.1 2.2 2.3 2.4 ... = 개발버전

3.0 = 안정버전(예상)

이런 식으로 버전이 바뀌었습니다. 1.x 시절과 다른 점은 점이 하나만 찍히게 되었고 지저분하게 올라가던 버전명이 사라지게 되었습니다. 이런식으로 버전이 올라가면 올해가 가기전에 3.0이 나오게 될 분위기인데요. 사실 점을 하나 없앴을 뿐이지 버전 올라가는 속도는 그대로인데 숫자의 크기가 무시무시하게 올라가다보니 굉장히 빨라진 것입니다.

그런데 모르는 사람들이 보면 엄청나게 버전업이 빠르다는 인상을 받게 됩니다. 저 부터도 갑자기 버전이 올라가는 것을 보고 개발속도가 빨라졌다고 생각이 들었으니까요. 물론 0.xx시절에 비하면 개발자들도 엄청 늘어났고 메일링도 늘어났으니 당연한 것이기는 합니다. 게다가 Wine-Staging의 존재가 개발 버전을 질질 끌 이유를 없애기도 했습니다. (물론 이 두 개발 그룹은 아무런 관계가 없습니다.)

이런 식으로 버전 이름을 올리는 것이 요즘 추세이긴 합니다. 크롬이 먼저 이런 식으로 올리면서 파이어폭스도 버전 숫자가 두 자리수를 넘어 세 자리수를 향해 가고 있고 리눅스 커널도 4.0이 덜컥 나오게 되었습니다. (정작 토발즈 형님께선 4.0으로 내놓는 것에 대해 떨떠름 하셨다고 합니다.)

이런 것이 나쁘다는 것은 아닙니다. 개발자들의 의욕을 올리는 것에는 매우 좋습니다. 다만, 사용하고 피드백하는 입장인 우리도 그것을 알고 그렇다는 것을 확인할 필요가 있기 때문입니다.

Wine을 업무용으로 쓰는 경우가 전세계적을 많이 늘었는데 업무용으로 개발 버전을 쓰는 것은 위험한 일입니다. 잘 되던 것이 안 되기도 하거든요. 업무는 시간이 곧 돈인데 Wine때문에 삽질을 한다면...? 리눅스를 업무용으로 쓰는데 당연히 지장이 생깁니다. 2.x부터는 이 사실을 알고 안정버전과 개발버전을 나눠서 사용하는 지혜가 필요할 것입니다.

참고로 Microsoft Office 2013을 쓰시려면 2.0으로 굴리세요. 2.1이상에서는 또 알 수없는 문제가 있을 지도 모른다고 합니다. Wine을 버전 별로 쓸 때에는 Playonlinux가 매우 좋습니다.

크랜치뱅이라 했던 배포판을 혹시 기억하시나요? 나름 꽤나 유명했던 배포판인데 저사양용으로 제작되서 상당히 가볍기로 유명했던 배포판입니다.

로고도 상당히 인상적이었는데

그냥

#!

이게 로고였습니다. 하지만 이 배포판은 결국 업데이트가 중단되고 말았고 아쉬움 속에 사라지고 말았지요.

하지만 2015년 6월 크런치뱅 제작자들이 다시 모여서 새로운 프로젝트를 시작했습니다. 일명 bunsenlabs란 배포판인데요. 그냥 크랜치뱅이 그대로 돌아왔다고 해도 과언은 아니더군요.

Openbox + tint2 + conky 그리고 몇몇 어플리케이션만을 넣고 배포되는 것으로 크런치뱅만큼 상당히 가볍습니다. 기본 상태로 메모리를 180MB를 먹고 있는 것이 확인 되었습니다. 여기서 더 가볍게 하려고 하면 더 가볍게도 가능할 지경입니다.

처음 설치는 Debian과 동일한데(Debian 기반이니까요.) OS설치후 이런 저런 것을 물어보는데 Backport저장소를 추가할 것인지 물어보는 때가 있는데 꼭 해주는 것을 추천합니다.

2017년 현재 Debian Jessie의 커널 버전은 3.1로 4.9가 넘어간 현재 버전에 비해 상당히 커널 버전이 낮습니다. 그리고 최신 하드웨어 지원도 별로입니다. 따라서 모든 OS의 설치와 설정이 끝난 다음 다음 명령어를 꼭 터미널에 넣어주시길 바랍니다.

sudo apt-get update

sudo apt-get install aptitude

sudo aptitude -t jessie-backports update

sudo aptitude -t jessie-backports upgrade

이렇게 해주시면 백포트 저장소를 통해 어느정도 패키지버전이 업그레이드 되는 것을 보실 수 있습니다.

그리고 깜빡했는데 기본적으로 한글폰트가 없으므로 꼭 한글 폰트를 설치해주시길 바랍니다.

sudo apt-get install fonts-nanum

더 가볍게 쓰고 싶으시다면 composite를 삭제하고 xfce4-power-manager삭제하고 수동으로 전원 관리를 해주시면 편리합니다.

sudo apt-get purge compton

sudo apt-get purge xfce4-power-manager

참고로 10년전 랩탑의 윈도7에서 버벅거리던 H.264 동영상 재생이 BunsenLabs를 쓰고 쌩쌩히 돌아가는 것이 확인 되었습니다. 뭔가 상당히 투박하지만 굉장히 가볍기 때문에 구형 하드웨어 재생용으로는 상당히 탁월한 것을 알 수 있습니다.

(스크린샷들을 날려먹었습니다.)

리눅스에서 알파벳 사용권 이외의 사람들이 자국어를 입력하고자 정말 많은 일들을 했습니다. 그리고 한국도 이와 다르지 않아 한글을 입력하고자 많은 사람들이 노력해왔습니다. 이는 Windows에서도 있었고 지금의 리눅스 환경에서도 있었습니다. Windows에서는 90년대만 하더라도 남극성이라던가 AsianSuite같은 것들이 쓰였습니다만 NT시대가 도래하면서 내부적으로 유니코드로 처리를 하게 되었고 기본 한글 입력기인 MS-IME 하나가 독보적으로 쓰입니다. (물론 새나루 같은 3rd-Party입력기도 있습니다.) 하지만 리눅스는 누구 하나가 독점적으로 주도해 나갈 수 없는 상황입니다. 그덕에 한글입력기가 여러가지가 나와있고 어느 하나가 낫다고 말을 못하는 실정입니다. 그 중 가장 많이 쓰이는 리눅스의 한글입력기 3종 세트를 비교해보도록 하겠습니다.

1. 나비(nabi)

2. 벼루(UIM-Byeoru)

3. 아이버스 한글(ibus-hangul)

우선 나비는 한국에 한국에 의한 한국을 위한 입력기 입니다. 무슨 말이냐면 나비는 다른 입력기와는 다르게 오로지 한국어와 영어만이 입력가능합니다. 다른 입력기는 입력 프레임워크위에 한글 입력기능을 추가하는 방식입니다. 하지만 나비는 그 자체만으로 한국어 입력을 위해 만들어졌기에 일본어나 중국어의 입력에 관해 전혀 고려가 되어있지 않습니다. 2004년에 처음 만들어진 나비는 거의 유일하다시피한 한글 입력기여서 많이 쓰였습니다. 하지만 업데이트가 상당히 더디며 새로운 라이브러리에 대응이 느린 덕에 아치리눅스 같이 빠른 업데이트가 생명인 배포판에서는 상당히 골때리는 상황이 자주 연출됩니다. 대표적인 것이 우분투의 Unity버그입니다. Unity가 나온지는 4년이 지난 지금도 입력기가 트레이에 들어가지 않는 버그가 있습니다. 하지만 LXDE나 MATE환경에서는 전혀 문제가 없습니다. 이외에도 QT5대응이 늦어져서 QT개발자들이 다른 입력기로 많이 넘어갔습니다. 여러모로 참 인력난에 시달리는 입력기라고 할 수 있습니다.

벼루는 일본에서 개발된 UIM프레임워크용 한글 입력 시스템입니다. 3종 입력기중에서 제일 오류가 적으며 호환성도 상당히 좋아서 보통 한글입력기를 추천하라고 하면 많이 추천하는 입력기입니다. 벼루 자체도 상당히 완성도가 높아서 Windows의 MS-IME의 입력과 동일한 입력이 가능합니다. 특히 리브레 오피스와 크롬에서 악명을 떨쳤던 끝글자 버그를 해결해버려 상당히 점유율이 높습니다. 지금은 다른 입력기도 해결한 버그지만 벼루가 제일 먼저 해결하여 상당히 선점 효과를 얻었습니다. 그러나 다른 입력기에 비해 메모리를 많이 먹는 것은 단점이라 할 수 있습니다.(UIM자체가 메모리를 많이 먹습니다.)

ibus는 우분투의 기본 입력 시스템으로 쓰이기에 우분투와 상당히 궁합이 좋습니다. ibus프레임워크는 중국에서 개발되었습니다. 즉, 개발팀의 규모가 UIM이나 나비와 상대가 되지 않습니다. 피드백도 빠르고 업데이트도 상당히 빨리 나오는 편입니다. 하지만 업데이트가 빠른만큼 버그가 상당히 많아서 한국어 사용자들에게 상당히 이미지를 많이 깎였습니다. 리브레 오피스에서 끝글자 버그라는 버그를 거의 7년 넘게 갖고 있었고 한영전환이 자유롭게 되지 않아서 수동으로 전환하는 삽질을 하게 되는 의외로 이런 일이 비일비재합니다. 하지만 또 그만큼 사용자층이 두껍다보니 다른 프로그램과의 호환성은 매우 좋습니다. 특히 Wine환경 같이 입력기의 호환성이 애매할 때는 그냥 ibus를 이용하면 한글 입력에 큰 문제를 안 일으킵니다. 무엇보다 입력기의 커버리지가 상당해서 전혀 생각지도 못한 언어도 입력이 가능하다는 점도 장점이라면 장점입니다. 다만, 한국어 사용자들의 피드백이 적은 탓인지 한글쪽은 입력기의 문제가 해결이 잘 안 되는군요.(한국은 워낙 피드백이 적어서 7년넘게 버그가 해결이 안 된다거나 합니다.)

무엇을 쓰던지 상관은 없습니다만, 결국 한국어를 입력하기 위해서 어떤 입력기를 사용하던지 큰 문제는 없을 듯 합니다. 다만, 개인적으로 UIM은 고사양용이며 ibus는 한국어에 한해 버그가 참 많습니다. Nabi는 업데이트가 늦습니다. 자 그래서 여러분들은 어떤 한글입력기를 쓰시나요?

현존하는 리눅스 데스크탑 중 가장 가벼운 데스크탑 환경은 무엇일까요?

분명 예전에는 XFCE가 가장 가벼웠다고 했던 것 같은데 어느새 LXDE라는 새로운 데스크탑 환경이 나와서 XFCE보다 더 가벼운 환경이 되었습니다. 그 뒤에 어느새 Enlightment라는 환경이 나와서 LXDE보다 더 가벼운 환경이라는 타이틀을 내걸게 되었더군요. 하지만 non-KMS 환경에서는 동작이 제대로 안 되는 등 Enlightment는 지향하는 바가 좀 다른 듯 하기는 합니다. 현재 KMS가 제대로 작동이 안 되는 초 구형 하드웨어에서 사용하려면 LXDE가 가장 가볍다고 봐야 합니다.

LXDE의 전체적인 모습. 어디선가 많이 본 듯한 느낌이 든다. 출처: LXDE.org

이러한 이유 덕분에 LXDE는 오래된 컴퓨터에서 돌아가야 할 때 많이 애용되고 있고 지금도 애용되고 있습니다. 헌데 이 LXDE가 새로운 모습으로 바뀔 예정이라고 합니다.

이름하여 LXQT입니다. 

LXDE의 다음세대라 할 수있는 LXQT의 모습. LXDE랑 별 다를바 없어 보인다. 출처: LXQT.org

갑자기 이름이 바뀐 것을 보면 근본부터 갈아 엎었다는 것을 알 수있을 겁니다. 네 LXQT는 기존의 LXDE와 연관이 별로 없습니다. 다만 개발자가 같고, 지향하는 바가 같습니다.(편리하면서도 가벼운 환경을 지향합니다.)

그런데 갑자기 멀쩡한 LXDE대신 LXQT가 개발되었을까요? 이유는 그래픽라이브러리 QT와 GTK에서 비롯되었습니다.

GTK는 그동안 LXDE를 통해서 잘 이용되어진 라이브러리입니다. 하지만, LXDE는 2010년 이후로 사용되어지지 않은 GTK-2버전을 이용해 왔는데 GTK-2는 GTK-3이 나오면서 개발이 중지된 라이브러리가 되었습니다. 그래서 LXDE의 개발자는 GTK-3과 QT5를 저울질 하던 중에 나온지 훨씬 오래되어서 상당히 안정화된 QT를 선택했습니다. 그리하여 LXQT가 나오게 되었고 지금 상당한 속도로 개발이 진행중입니다. QT만 설치하면 지금 당장 우분투에서 가동도 가능합니다.

몇몇 PPA를 등록해야 하기는 하지만 아직 개발중인 것이니까 그러려니 합시다.

이와 같은 명령어로 우분투에서 LXQT를 사용할 수 있습니다. 하지만 LXDE와 큰 차이는 못 느끼겠습니다. 하지만 LXDE를 사용하신다면 슬슬 LXQT로 넘어가실 준비를 해야 할 것입니다. 개발자가 LXQT를 개발하고 있는 이상 LXDE는 도태될 확률이 높습니다. 그리고 Lubuntu의 Daily-update채널에 LXQT가 올라오고 있는것을 봐서 다음 Lubuntu는 LXQT기반일 것이 확실합니다. 이로써 LXDE의 도태는 기정 사실 이게네요. LXDE를 사용하시던 분은 LXQT의 Lubuntu가 나온다면 꼭 이렇게 이야기 합시다.

LXDE 그동안 고마웠어!

제목은 한글문제입니다. 이번에 이야기 할 것은 한컴의 워드프로세서가 아니라 우리가 지금 사용하는 바로 이 한글을 말합니다.

리눅스는 아시다시피 오픈소스로 공개된 커널을 기반으로 이리저리 손을 대서 만들어낸 물건입니다. 따라서 모든 세계인들이 활용 할 수 있게 만들어야 하고 또 그렇게 되고 있습니다. 그런데 워낙 리눅스 이용 인구가 적은 한국은 한글 문제에 자주 봉착합니다. 아니 한글 자체가 문제가 아니라 UTF-8과 EUC-KR의 호환문제, 게다가 Microsoft만 만들고 쓰는 CP949같은 코드 파편화 문제입니다. 사실 한글을 읽고 쓰는 것은 전혀 문제가 없습니다. 유니코드라는 국제 표준이 나오면서 전세계의 언어를 통합 관리하게 되었기 때문에 이 유니코드만 사용한다면 한글문제, 아니 전세계의 모든 언어의 문제는 해결이 가능합니다.

문제는...... 표준을 지키지 않는 것들입니다. 저는 "비표준"이나 "사실상의 표준"을 참 싫어합니다. 비표준이야 어쩔  수 없는 경우가 많다고 해도(예를 들면 M5.5같은 애매한 나사라던가....이건 M5나 M6을 쓰면 안 되나?) 사실상의 표준이라고 이를 고수하는 것도 좀 웃기다는 생각이 듭니다. 사실상의 표준이라면 이를 표준으로 지정하면 되는데 ISO에서 이를 표준으로 지정하지 않는다?

대체 무엇이 문제일까요? 대표적인 것이라면 플래시가 있습니다. 브라우저 플러그인 방식인데다가 멀티코어 사용에 문제가 있고, 어느 한 회사(Adobe)의 독점 형태로 제공되고 있다 보니 문제가 참 많습니다. 하지만 그래픽적 효과를 이렇게 쉽게 보여줄 수 있는 녀석도 없어서 플래시는 지금 웹 그래픽에서는 표준이다시피 합니다. 하지만 HTML5에서 플래시의 기술은 들어가지 않았습니다. 넣으려면 넣을 수도 있었을텐데 말입니다. 그 이유는 모바일 플래시를 써보신 분들은 아시겠지만 엄청난 연산량에 따른 문제라고 하는군요.

그러고보니 반대로 한 회사에서 만들어서 쓰다가 ISO의 표준지정으로 바뀐 기술도 있습니다. 바로 PDF! 그러고 보니 이 물건도 Adobe의 결과물이군요. PDF는 현재 문서표준으로 지정되어 있어서 모든 기술이 공개되어있습니다. 위의 플래시 기술이 완전공개가 되지 못한 것(플래시 기술의 일부는 공개가 되어있습니다. 오픈소스의 결과물이라고는 하지만...)과는 차원이 다르지요.

자 다시 한글 표준으로 돌아와서 이제 어떤 문제가 있는지 확인 해 봅시다. 먼저 MS는 CP949라는 뭔가 해괴한 EUC-KR호환 한글코드를 사용합니다. 그 와중에 내부에서는 유니코드를 사용합니다. (뭐하는 짓이야...) 그리고 KS표준에 보면 EUC-KR과 유니코드를 동시에 올려놓았습니다. 그리고 UTF-8이라는 유니코드와 아스키 호환 코드도 존재합니다. ISO는 당연히 유니코드만이 표준입니다.

네 점점 가관입니다. 특히 KS표준이 참 막장이네요. EUC-KR과 유니코드를 같이 표준으로 채택하는 바람에 통일이 이루어지지 못했습니다. 그럼 CP949는? 이건 표준 아닙니다. 그냥 MS가 만들어낸 확장 완성형 기반입니다. 마치 옛날에 조합형 vs 완성형 싸움 비슷한 생각이 드는군요. 현재로써는 완성형이 이긴 것 같기는 하지만 한/글 워드프로세서가 조합형을 썼기에 지금의 위치에 오른 것을 생각해보면....

이러한 문제는 멀리 갈 것도 없이 UTF-8을 기본으로 사용하는 리눅스/OSX에서 윈도에서 압축한 ZIP파일을 풀면 여실히 드러납니다.한글 파일명이 대책없이 깨집니다. CP949는 EUC-KR 호환이라고 했지요? 원인은 여기있습니다. 때문에 반디집같은 프로그램은 UTF-8환경을 한번 거치는 것 같기는 합니다만,(한글이 아닌 다른 외국어로 쓰인 파일명을 읽기 위함 그런데 이것이 UTF-8에서 압축한 한글에도 먹히는 것입니다.)

언제나 매번 문제를 일으키지만 해결될 기미가 안 보이는 한글문제... ISO의 권고사항만 지키면 큰 문제는 없을 것 같은데 왜 안 지키는 사람들이 많을까요? 제발 적당히 배운티 내지 않았으면 좋겠습니다.

이번에는 무진장 딱딱하고 재미없는 글을 올릴 차례입니다. 물론, 지금까지 재미있는 글은 없었지만 이번에는 더 딱딱한 이야기를 해보려 합니다.

많은 사람들은 아직도 리눅스를 엄청 딱딱하고 어려운 운영체제로 알고 있습니다. 원인이야 뻔하지만, 리눅스를 사용해본 사람들은 리눅스 자체가 어려운 것이 아니라 사용 방법이 틀렸다는 것을 알고 있습니다.

사실 리눅스를 데스크탑 운영체제로 사용하게 된 것은 그리 오래되지 않았습니다. 리눅스는 사실 서버 워크스테이션에 쓰이던 Minix의 카피였고(리누즈 토르발즈 자서전에 나와있습니다.) 그 리눅스라는 커널보다 사용자의 완전 분리라는 독특한 매력에 사람들이 빠졌다고 합니다. 즉, 한 컴퓨터에 여러사람이 달려들어도 서로 다른 환경을 쓰는 것 같은 느낌을 줬다고 합니다. 윈도 사용자분들은 1인 1PC시대에 살고 있는데다가 보통 관리자 모드로 사용하기 때문에 (UAC로 어느 정도 막고는 있지만)어떤 것인지 잘 모르겠지만, 관리자는 따로 있고 사용자들은 오로지 User모드만 사용하는 것이지요. 어떤 프로그램을 설치하고 싶으면 관리자에게 연락해서 설치해 달라고 해야 했고, 그 관리자의 계정은 언제나 root였기에 root계정이 해킹당하면 말그대로 시스템이 장악되었습니다.

무슨 소리인지 잘 모르겠다고요? 그냥 당시의 컴퓨터는 원격으로 접속해서 사용해야만 하는 컴퓨터였고(그래서 워크스테이션이라고 따로 지칭한 것입니다.) 이 때 관리자와 유저는 엄격히 구분되어야 했습니다. 사실 Unix시스템의 전반이 다 그러했습니다. 그런데 리눅스가 어렵다는 편견은 아마도 여기서 시작된 것 같습니다.

사실 윈도는 윈도XP시절부터 사용자를 제대로 분리하기 시작했습니다. 그전의 98시절에도 충분히 사용자분리 옵션은 있었지만 바탕화면이 공유되는 등(...) 말도 안되는 사용자 분리를 택했기 때문에 아무도 그런 기능이 있었는지도 몰랐습니다. 심지어 어떤 사용자모드를 쓰더라도 시스템의 근본까지 장악 가능했으니(리얼 도스모드 진입가능→ 하드웨어 직접 접근 가능)사용자 분리의 이점이라고 눈꼽만큼도 없었습니다. 대신 그만큼 개인이 신경 쓸 거리는 줄기는 했습니다. 그러다가 윈도NT계열이 가정용으로 들어오면서(즉, XP시절 이후를 말합니다.) 기존 NT가 했었던 것처럼 사용자 분리를 시도했는데 현실은 그냥 유저 구분없이 모두함께 관리자 모드로 사용... 윈도 비스타시절부터 UAC란 놈을 들고와서 관리자 권한이라도 경고를 한다던가 한번 필터링을 하는 방식도 취해봤지만 이미 전반적인 생태계가 관리자 권한을 요구하는 괴상한 형태로...

즉, 윈도 사용자들은 권한 분리가 익숙하지 않습니다. 그에비해 워크스테이션으로 시작된 OS인 리눅스는 이를 엄청 중요시 여깁니다. 관리자 권한 해킹당하면 해당 워크스테이션을 사용하는 모든 사람들의 정보가 전세계로 솟구칠테니까요.(혹은 삭제당하거나) 처음 리눅스란 것을 본 사람들은 여기서 짜증을 내기 시작했'었'습니다. 왜 과거형이냐면 기존 윈도 사용자들이 UAC덕에 관리자 권한으로 실행하는 것에 익숙해지기 시작했거든요. 물론 아직도 UAC가 뜨면 당황하는 사람들이 태반이기는 하지만 이제 좀 관리자 권한에 대해 이해를 하기 시작한 사람들이 보입니다. 그런 사람들에게 리눅스를 보여주고 su나 sudo 혹은 gksu같은 명령을 알려주면 그게 "관리자 권한으로 실행"이라는 것을 곧잘 이해하더군요.

(물론 아직도 이해 못하는 사람 많습니다. 왜 관리자 권한이 필요한 이유조차 모르기 때문이지만...)

그런데 우분투같은 사용자 편의를 중시한 배포판에서는 언제부터인가 관리자 권한 확인이 UAC 비스무리한 모습으로 만들어지더군요. 즉, 권한분리에 익숙치 않은 사용자들을 위해서인지 그냥 권한 분리를 윈도스럽게 해놓았습니다. 우분투가 쉽다고 하시는 분들 중에는 이러한 이유도 있습니다. 다른 배포판에서는 기본 세팅상태를 기준으로 유저모드로 sudo 명령을 쓰면 대부분 안 먹습니다!(데비안이나 페도라 기준) 우분투처럼 쓰고 싶으면 /etc/sudo내의 있는 설정파일을 수정해야만 하고 수정을 하려면 root로 로그온 해야합니다. 즉, 관리자의 손길이 필요하다는 것이지요. (이 이야기는 데비안 기준이고 페도라는 좀 다르다고 알고 있습니다.)아, 대신 우분투는 root권한 자체가 숨겨져 있습니다. 마치 윈도에서 Administrator계정이 안전모드에서만 나오는 것과 비슷합니다.

이쯤되면 리눅스는 어렵다는 것은 일부 배포판에 한정해서이기는 하지만 조금 완화 되었을 것이라고 생각이 듭니다. 자신의 정체성 중 일부를 수정하면서 까지 윈도스럽게 수정했으니까요. 소프트웨어의 부재는 전에도 말했듯이 wine이나 Virtualbox로 극복이 가능한데다가 전용 소프트웨어도 상당히 훌륭합니다.예전에는 제품개발은 어쩔 수 없이 윈도에서 했지만, 요즘은 제품개발도 리눅스에서 가능해져 가고 있습니다.(DraftSight와 CATIA의 wine 실행 - 이놈은 태생이 유닉스 용입니다.)

리눅스가 어렵다는 것은 편견이라고 했습니다. 리눅스의 대표적인 데스크탑 배포판인 우분투는 이미 윈도 사용자를 상당히 배려했습니다. 그런데도 많은 사람들은 리눅스를 어려운 운영체제로 믿고 있습니다. 일단 까더라도 사용해보고 깠으면 좋겠습니다.

오늘의 글은 정말 말 많고 탈 많은 AMD(구 ATI)의 리눅스 지원에 대한 글입니다.

감정적으로 엄청 까는 글이므로 보시기 싫으신 분들은 봐주시지 않으셨으면 좋겠습니다. 까는 글이므로 그림이나 사진을 넣는 것을 최대한 뺴려고 합니다. 정말 화가 머리끝까지 솟구쳐서 하는 이야기이므로 AMD그래픽을 좋아하신다면 반대로 화가 나실 수도 있습니다.

우선 AMD로 인수되기 이전의 말 많고 탈 많은 이야기부터 시작합니다.

리눅스나 BSD 계열은 예전에는 많은 양의 3D 그래픽을 요구하지는 않았습니다. 그 정도의 3D 연산을 요구하는 프로그램이래봐야 CATIA (~v4) 정도? 였습니다. 그나마도 3D CAD프로그램은 워크스테이션 여러대를 이어서 돌리는 것이었으니 지금과 같은 직접적인 GPU연산을 필요로 하지는 않았습니다. 그냥 OpenGL가속에 도움이 되는 정도 였습니다. 물론 이 당시에 fglrx라는 놈이 ATI사에서 개발되어서 유닉스 기반 3D연산에 상당히 도움이 되기는 했습니다. 90년대의 3D CAD관련 글을 보면 이에 대한 글이 있을 정도로 fglrx는 고마운 존재였다고 합니다. 물론 ATI의 그래픽 중에서도 FireGL그래픽카드만 적용 가능했지만 당시의 3D CAD는 고가였고 전문가만이 사용가능한 프로그램이었습니다. 그 외의 3D 연산을 필요로 하는 것은 게임 정도였지만 당시의 유닉스는 게임을 돌릴 이유가 없었습니다. 애초에 3D게임도 많이 부족했습니다.제대로 된 3D 게임은 95년쯤에야 나왔으니까요.

그러던 어느날 리눅스 데스크탑이 시장에 나오고 갑자기 뜨기 시작했습니다. 하지만 이 당시에도 리눅스 데스크탑은 중요한 위치에 있지 않았고 3D 가속은 안중에도 없었습니다. 그 당시에는 멀티미디어가 주류였고 이 당시에 Mplayer 같은 놈들이 개발되어서 애용되어집니다. 3D 연산은 필요했지만 있으면 좋고 없으면 말고 수준이었습니다. 리눅스를 사용하는데 필수는 아니었으니까요. 리눅스 데스크탑이 나오고 X의 발전이 이루어졌지만 당시의 X는 2D 가속에 초점이 맞추어져 있었습니다. 그리고 각종 그래픽 칩셋의 프레임버퍼 드라이버들이 세상에 나와서 X에 들러붙게 됩니다. (nv, ati, tdfx, i810 등등의 이름으로 나왔습니다. 척 보기에도 어떤 그래픽드라이버인지 알 수 있지요?) 당시의 커널은 오로지 프레임버퍼만 제공했던 것으로 기억합니다. GUI뿐만 아니라 2D 프레임 버퍼도 X의 유저모드로 전부 제공했기에 xorg.conf 파일(X설정 파일)은 하나라도 잘못 설정하면 그냥 데스크탑 전체가 바보가 되버리는 어마어마한 양의 설정 파일이었습니다. 하지만 이것도 크게 중요하지는 않았습니다. 일단 GUI만 띄우는 데에도 엄청난 노력이 필요했으니까요. 물론 이 때에도 fglrx나 nvidia 같은 바이너리형 독점 드라이버들이 있기는 했습니다. 쓰는 사람만 썼기에 그렇지...

그러던 어느날....

2005년이었던 것으로 기억합니다. 아니, 2004년이었나? 오픈수세로 유명한 노벨이라는 기업에서 XGL이라는 것을 발표하고 공개를 했습니다. 그리고는 3D 가속환경하에서 엄청난 데스크탑 효과를 보여주며 GUI란 이런 것이라고 보여주게 됩니다. 지금의 윈도7,8의 창 효과정도는 버로우 시킬 정도의 화려한 효과였습니다. 사실 맥에서는 이와 비슷한 효과를 이미 사용하고 있었습니다. 이를 따라한 것이기는 한데, 역으로 말하면 리눅스 데스크탑에서도 맥처럼 상시 그래픽 가속이 가능하다는 이야기가 됩니다. 덕분에 리눅스 커뮤니티에서는 이를 적용하기 위해서 삽들을 뺴들기 시작했고 폭발하기 시작했습니다. 이후 이 3D데스크탑 효과기능은 Beryl등의 이름을 거쳐서 Compiz-Fusion이란 이름으로 나오게 되는데 이 당시의 삽질은 정말 어마어마했습니다. 각 리눅스 배포판들은 이를 적용하려면 XGL을 기존의 X를 버리고 설치해야 했는데 이게 꽤 엄청난 삽질이었거든요.XGL을 성공적으로 설치했다고 한들, 그래픽 드라이버가 DRI(즉, 직접 렌더링)이 지원되지 않으면 말짱 꽝이었습니다. 드라이버 소스가 공개되어있던 인텔을 제외한 다른 오픈소스 드라이버들은 DRI가 잘 안 되었고, 자신의 칩셋에 대해 잘 아는 회사들만이 드라이버를 내놓을 수 있었습니다. 이 때 빠르게 드라이버를 내놓은 곳은 여전히 fglrx란 이름으로 내놓았던 ATI였지만, 무슨 생각이었는지 Compiz가 말을 안 듣는다거나 커널패닉을 일으키거나 하는 이유로 말썽을 일으키게 됩니다. 반대로 Nvidia는 무슨 짓을 한 것인지, 굉장히 안정적인 드라이버를 내놓습니다. 지금도 비슷하지만 워낙 ATI의 드라이버가 막장이었기에 멀쩡한 ATI카드를 버리고 한 단계 낮은 Nvidia카드로 갈아타는 사람도 있었습니다.

XGL적용삽질이 한창 이루어질 때 즈음, 리눅스계의 독보적인 기업인 레드햇에서 GLX라는 것을 내놓게 됩니다. XGL과 이름이 비슷하지요? 기능은 사실상 동일 하지만 이는 기존 X를 갈아치우지 않고 X에 패치형태로 적용한 물건입니다. 즉, XGL이 기존 X와 어느정도 호환성을 갖추고 쌓아올린 물건이면 GLX는 기존 X를 이리저리 개조해서 만든 물건이라는 것이지요. 그리고 Compiz는 둘 다 적용 가능하게끔 개발이 이루어지게 되어서 배포판은 선택의 기로에 서게 됩니다. 이 선택의 기로는 그래픽 드라이버도 마찬가지였다고 합니다. 예전부터 fglrx를 내놓던 ATI는 XGL을 선택했고 Nvidia는 GLX 쪽으로 가닥을 잡았던 듯 합니다. 하지만 웃긴 것은 GLX를 쓰던 XGL을 쓰던 Nvidia는 별 문제가 없었는데, ATI는 GLX를 쓰면 난리를 쳤습니다. 드라이버 개발능력이 경쟁사보다 딸리는 것인지 대체...

2007년에 가장 다운로드수가 높았던 배포판인 우분투는 XGL과 GLX 둘 다 가능하게끔 설정을 하기는 했는데, 이 당시의 글을 보면 독점 드라이버 설치가 정말 거지같았던 것을 알 수 있습니다. 이리하면 저곳에서 뻑나고 저리하면 이쪽에서 뻑나고 커널 업데이트하면 또 뻑나고...어휴... 그리고 Compiz(당시는 Beryl이었나요?)를 설치하면 그대로 GUI가 사라지는 등...캐노니컬에서도 이를 인지 했는지 이후 8.04라는 역대 최고의 안정적인 버전이 나오면서 그래픽드라이버 설정을 간단하게 마우스 한 두번 클릭으로 바꾸고(아니면 설치 중에 드라이버 설치 한다고 물어봅니다. 지금도 그렇기는 하지만)기본 3D X환경을 GLX로 가게 됩니다. 그리고는 Compiz를 기본 탑재해버립니다. 그 덕이었을까요? 다른 배포판 들도 XGL대신 GLX를 선택해버리고(사실 기존 X를 개조한 수준이라 딱히 수정할 곳이 없어서 그냥 X를 설치하면 되니까 XGL에 비해 메리트가 있었습니다.) XGL에 별다른 메일링이 없어져 버렸습니다. 즉, XGL이 도태되어져 버린 것입니다. 덕분에 ATI는 발등에 불 떨어졌지요. GLX만 쓰면 난리를 쳐대는데, 이를 해결해야 했으니까요. 당시의 회고에 따르면 fglrx만 설치하고 Compiz환경으로 만들면 그대로 하얀화면으로 되어버리는데, 우분투는 기본적으로 compiz를 쓰다보니 우분투를 쓰면서 fglrx를 쓸 수가 없었다고 합니다.그나마 오픈수세는 XGL을 탑재했다보니 큰 문제는 없었는데, 이마저도 XGL이 도태되면서 노벨에서도 GLX를 적용한 X를 탑재하기에 이르릅니다. 그동안 ATI는 삽질을 계속했습니다.

당시의 드라이버에 대해 말씀드리지면 윈도용 Catalyst는 물론이고 리눅스의 fglrx도 해커들이 개조를 해야 쓸만하다는 평을 들을 정도로 참 드라이버가 막장이었습니다. 윈도용도 막장이었는데, 개발팀이 훨씬 적은 리눅스, 유닉스 용은 뭐...말을 말아야지요.

그래서였는지, ATI는 중대 발표를 해버립니다. 나온지 3년 밖에 안 된 X시리즈(R500)까지의 드라이버 지원을 중단 하겠다고 선언을 해버립니다. 즉, 과거의 칩셋에 대한 지원을 끊음으로써 드라이버 개발에 더 많은 지원을 하겠다는 것이지요. 이는 윈도+리눅스+기타 OS 전부 통하는 이야기였습니다. 그리고 정말로 드라이버가 개변한 시기는 AMD에 인수되고 몇 년 지난 2013년이 되어서야 쓸 말한 드라이버소리를 듣게 됩니다. 과연 이것이 잘 한 것인지 아니면 무리수였는지는 모르겠지만, 덕분에 당시 나온지 3년밖에 안 된 X시리즈 사용자들은 엿을 먹게 되었습니다. 드라이버 지원은 레거시라는 이름 하에 해주겠다고 했지만 그나마도 2009년에 끊었습니다. 윈도는 어땠냐구요? 기존에 제공된 드라이버 해킹해서 적용하고 있습니다. 무슨 We Are The World도 아니고...

이 무렵 Nvidia는 그냥 쿨하게 싹 다 지원하는 방향으로 가게 됩니다. 8800GT가 나오면서 이전의 드라이버를 끊기는 했지만, 이전 드라이버들이 최신 OS에 적용할 수 있게끔 지원을 해줍니다. 예를 들이서 96.xx 버전은 XP까지만 지원이 가능한 드라이버지만 윈도8에서 설치가 되게 끔 해주는 것입니다. 실제로 96.xx 버전을 윈도8에서 설치하면 지원 하드웨어(즉, Geforce 4 이전의 물건)의 구동이 무리없이 됨을 알 수 있습니다. (물론 완벽하지는 않아서 버그가 있기는 합니다.) 그에비해 Catalyst는 이 짓을 하면....까만화면을 보게 됩니다.(OS 가리지 않는 WDM기반이라며? 이건 대체...???)리눅스도 사정이 비슷해서 지금도 구형 하드웨어에 최신 우분투를 설치하면 Nvidia칩셋이라면 상당히 구버전인 96.xx나 1xx.xx 를 설치 할 수 있게끔 되어있습니다. ATI칩은???? 안 되요. 설치하면 까만화면만 보게됩니다.

자 아까 GLX와 XGL 지원에 대한 이야기를 잠깐 했었지요? ATI는 XGL위주로 가게 되었는데 XGL이 도태되면서 하는 수 없이 GLX지원으로 방향을 틀게 되고 이는 어마어마한 버그의 향연으로 이루어지게 됩니다. 한달에 하나씩 나오는 주제에 버그가 수정되지도 않은채 나오기도 하고(hex 에디터로 수정해서 쓰는 사람도 있었습니다. 물론 방법을 공개했으니 이를 배포판에서 적용해서 내놓기도 했습니다. 이게 어떻게 독점 드라이버지...?) 경쟁사는 어땠을까요? Nvidia는 GLX를 쓰던지 XGL을 쓰던지 큰 문제는 벌어지지 않았습니다. 그러니 GLX로 넘어가더라도 XGL관련 코드만 삭제하면 그만이었으니 문제는 전혀 없었습니다. 이 쯤되면 ATI는 욕을 바가지로 퍼 먹어도 할 말 없습니다. 덕분에 리눅스는 당시의 인텔2D가속 문제와 함께(당시 인텔은 동영상 티어링 문제로 말이 많았습니다.) 무조건 Nvidia라는 분위기가 형성되게 됩니다. 이후에 인텔의 문제가 해결되며 문제를 일으키는 GPU제조사는 ATI뿐이었습니다.(다른 S3등은 제조사 도움없는 오픈소스 드라이버 뿐이었으니 무시합시다. - 인텔은 제조사 도움을 받는 오픈소스 드라이버였음)

이후 ATI가 AMD에 인수되며 자금사정이 나아지며 드라이버 지원이 나아지는 듯 했습니다. 하지만 현실은 시궁창. Nvidia가 각종 삽질을 하고 AMD에 비해 높은 가격을 받지만, 리눅스에서는 여전히 Nvidia가 선택 될 수밖에 없습니다. 물론 ATI가 R500이하 시리즈의 드라이버 지원을 끊을 때, 기술문서를 공개 함으로써 오픈소스 드라이버 개발지원을 해주기는 했습니다. 그래서 오픈소스드라이버가 개선되어졌냐고 하면 Catalyst 설치시의 40%성능도 채 안 나옵니다. 제가 보기에는 그냥 지들이 드라이버 개발능력이 안 되니까 커뮤니티에 떠 넘긴듯한 인상이 듭니다. AMD로 넘어간 지금도 사정이 거기서 거기라 Catalyst가 안 돌아가면 고성능 3D 연산은 포기해야 합니다.

제가 리눅스를 쓰면서 언제나 느끼는 것이지만 다시는 ATI(AMD)칩 쓰는 하드웨어는 이제 안 사려고 합니다. 이 고통은 그냥 돈으로 해결하는 것이 답일 듯 합니다. 아무리 칩을 잘 만들면 뭐합니까? 아무리 싸게 내놓으면 뭐 합니까? 제가 쓰기에 불편하면 그건 그냥 실리콘 덩어리입니다. 하드웨어 설계능력이 좋아도 소프트웨어가 거지같으면 병신 된다는 것을 너무 뼈저리게 느끼고 있습니다. 더군다나 리눅스는 하드웨어를 보통 안 바꾸니 (서버 위주로 사용하면서 일부 계층은 최적화를 중시한다는 것을 감안합시다.)소프트웨어 지원이 절실한데 리눅스를 윈도지원 하듯이 하는 것은 아니라고 봅니다. 다시는..다시는 안 쓸겁니다. AMD GPU...

http://distrowatch.com/

Distrowatch 의 첫 화면 굉장히 정신사납지만 이 첫 화면에 올라오는 배포본이 인기도 많다. 제일 중요한 다운로드 수는 오른쪽 아래에 있다. 1위는 Mint 우분투는 2위다.

Distrowatch란 각종 오픈소스 프로그램과 리눅스 배포판(사실 BSD나 다른 계열 OS도 상당히 많이 있습니다.)들을 비교 분석 해주는 사이트입니다. 하지만 다른 것보다 절대적인 영향력을 보이는 것이 배포판의 인기 순위인데요. 보통 이곳에서 메이저 배포본이라 하면 많이 다운로드 받고 사용자층이 두터운 것을 말합니다.

사용자 편의?

안정성?

이런 것은 분석하는 곳에 들어가지 않습니다. 패키지에 대해서는 올라오지만  해당 패키지의 질에 대해서는 따로 언급 안 하더군요. 여기에서 제일 좋은 것은 업데이트 자주 되고 사람들이 많이 다운로드 받는 것이 제일 좋습니다.

이 업데이트가 자주 되는 것에 대해 제일 큰 피해를 본 배포본이 Debian입니다. 안정성을 위해 보수적인 노선을 택했는데 이것을 Distrowatch측에서 도리어 안 좋게 보는 바람에 한 때는 배포본 품질에 빨간불이 켜져있기도 했습니다. 지금은 개선 되어서 적극적인 개발을 하는 배포본으로 뜹니다만, 배포본 성향을 생각하지않고 기계적으로 분석을 하다 보니 문제가 생겼던 것입니다. 데비안의 사용자 층이 우분투 출시 이후에 떨어진 것도 사실은 여기의 영향이 없지 않다고 합니다. (당시 우분투와 데비안의 차이는 거의 없었고 우분투에서 데비안으로의 전환도 가능했던 시기입니다. 하지만 갑자기 우분투의 인기가 마구 올라갔는데 Distrowatch의 덕도 있다고 합니다.)

보통 리눅스를 추천할 때 사람들에게 어떤 것이 어떻고 어떤 것은 어떻다고 말하기가 참 어렵지요. 막말로, 제가 우분투보다 루분투가 더 가볍고 쿠분투는 조금 무겁다. 이렇게 말해봐야 선택하는 사람 머리만 더 아플 뿐입니다. 어차피 리눅스 쓰려고 한다면 인터넷에 검색했을 때 방법이 바로바로 나오고 포럼에 질문하면 답변이 후다닥 나오는 그런 배포판을 추천 할 수 밖에 없습니다. 자신이 리눅스를 잘 안다고 해도 시스템에 문제가 생기면 인터넷 검색이나 포럼 질문 등을 통해 해결해야 하는 것은 매 한 가지니까요.(이는 윈도도 마찬가지이기는 합니다. 다만 워낙 사용자 층이 넓고 깊어서 대충 검색해도 해결책이 나오다보니 별 문제를 못 느끼는 것입니다. 마이크로소프트의 특유의 묻지마 기술지원도 한 몫 하고요.)

그럼 제일 사용자 층이 두터운 것을 추천 할 수 밖에 없습니다. 그럼 사용자 층을 확인 할 수 있는 방법은? 여기 Distrowatch밖에 없네요... 이 Distrowatch의 1인자는 현재 Mint입니다. Debian이나 Fedora, OpenSUSE 등도 상당히 인기가 높고 포럼도 굉장히 활성화 되어있지만 상당히 큰 차이를 보이고 있네요. 사실 이렇게 된 까닭도 Mint가 잘 만들어져서 그렇기도 하지만 Distrowatch의 인기 배포판이라 그럴 수도 있습니다. 실제로 우분투 11.04의 Unity대란이 일어났던 시절 저처럼 다른 배포판을 찾아보던 사람들은 Fedora나 Debian등으로 넘어간 사람도 많았지만 당시 Mint가 2위였기 떄문에 Mint를 선택한 사람도 많았습니다. (그리고 무한 반복입니다.)그리고 지금은 Mint가 우분투를 제치고 인기 순위 1위가 되었습니다.

결론은? 부익부 빈익빈입니다. 민트나 페도라 같은 상위권 배포판이 삽질하지 않는 이상 하위권 배포판들은 상위권 진입이 상당히 어렵습니다. 그렇다고 리눅스 초보자에게 하위권 배포판을 추천 할 수는 없으니 하위권 배포판은 기존 리눅스 유저가 넘어오기를 기대 하는 수밖에 없습니다. 이것도 다 Distrowatch의 영향 때문이라고 봐야할 것 같습니다. 지금도 수많은 배포판들이 Distrowatch에 홍보 중이기는 합니다만, 그냥 그렇구나 수준으로 구경만 하게 됩니다. 혁신적으로 만들어서(MAUIOS처럼 Xorg대신 Wayland를 쓴다던가 Kali처럼 해킹툴을 내장(...)했다던가) 배포 되지 않으면 여기에 올라왔다고 순위에 올라가지는 못할 듯 합니다.

Distrowatch가 전체 OS시장에서 5%도 안 되는 곳에서도 영향이 이렇게 큰데 만약 리눅스가 전체 데스크탑OS의 10%이상을 점유한다면 이 사이트는 전쟁터가 될 듯 합니다. 그러기에는 아직 시간이 많이 걸릴 듯 하지만, 제가 생각하는 미래가 올 때까지 Distrowatch가 살아있었으면 좋겠군요. 물론 그 때도 여전히 부익부 빈익빈 일 것 같기는 하지만...

간만의 포스팅이군요. 한동안 Long Live The Queen 한글패치 관련 작업 및 다른 일 떄문에 글을 전혀 올리지 못했습니다. 이제 원래 블로그 주제에 맞는 글을 다시 올려야지요. 다시 한번 말하지만 여기는 우분투/리눅스민트 사용 및 리눅스에 대한 이야기를 적는 블로그니까요. 기타 삽질 카테고리가 우분투 카테고리보다 늘어나면 블로그명 부터 갈아엎을 겁니다.

이제 서론은 그만두기로 하고, 이번 포스팅 주제를 다시 이야기 하도록 하겠습니다. 이번 포스팅 주제는 지는 해 Xorg와 뜨는 해 Wayland에 대해 써보도록 하겠습니다.(뜬금없이 나타난 해 - Mir는 제대로 공개가 되면 이야기 해봅시다.)

1. Xorg 이것은 무엇일까?

Xorg는 최초의 GUI 시스템인 X윈도우(X11)의 일종입니다. XFree86이 최초의 GUI 구현체였지만 이것이 라이센스가 꼬이면서 사람들은 마지막으로 라이센스가 GPL이었던 버전을 그대로 Fork해서 새로이 만들어내었습니다. 이쪽은 라이센스가 여전히 GPL 혹은 LGPL이었기에 커뮤니티 기반의 리눅스/유닉스 배포판에서 환영을 받았습니다. 물론 대부분의 배포판이 전부 Xorg로 넘어간것도 다 라이센스문제 때문이었지요. 특히 GPL이 꼬여있는 것이 문제였습니다. (이후에 비슷한 일이 OpenOffice.org와 LibreOffice에서 일어납니다.)

그런데 Xorg는 바로 전에 말했듯이 기존의 만들어졌던 XFree86의 후손이기에 소스코드가 XFree86기반이었고, 이 소스는 자그마치 80년대에 만들어진 코드였습니다. 즉, 만들어진지 30년이 된 시스템을 이리저리 때워가며 만든 것입니다. 그런데 2010년대에 들어선 지금에도 대다수 리눅스/유닉스의 GUI는 거의 Xorg 혹은 XFree86입니다. 사실 그동안 많이 쓰이기도 했고 대다수 프로그램들이 이 X11기반으로 돌아가기 때문에 당연하게도 이 Xorg를 이리저리 고쳐서 쓰는 실정입니다. 사실 중간에 격변을 거치기는 했습니다. 문제는 격변이 덩치 불리기로 이루어져서 코드 최적화가 더 이상 불가능할 정도로 안드로메다로 날아가 버렸다는 것이 문제입니다. 그리고, 새로운 그래픽 카드들은 계속 나오고 있고, 이를 지원하기 위한 각종 기술들이 들어가기 시작했고, KMS나 DRI, AIGLX 등의 많은 기능이 추가되게 됩니다. 문제는, 이를 다 쓰기에 Xorg는 너무 낡은 코드를 사용했고, 가벼운 데스크탑을 지향하기에는 조금 무리가 따르게 되었다는 것입니다. 그러던 어느날, Wayland란 녀석이 눈에 띄게 되면서 이 물건이 Xorg의 자리를 노리기 시작합니다.

2. Wayland의 정체

Wayland는 사실 레드햇 개발자가 따로 떨어져나와 시작된 프로젝트였습니다. 꼭 필요했던, 하지만 아무도 시작하지 못했던 그런 프로젝트였지요. 그런데, Wayland 이놈은 대부분 기능을 커널에 넘겨버리는 짓을 합니다. 즉, 커널이 디스플레이의 대부분을 담당하게 하면서, 자신의 몸집을 줄이는 방향을 택한 것이지요. 사실 KMS와 DRI기능이 커널에 들어가면서 이것이 가능하게 되었는데, 지금 사용하는 리눅스 데스크탑은 전부 사용하고 있는 기술입니다. 언제부터 갑자기 xorg.conf 삽질을 하지 않아도 알아서 해상도가 잡히고, 입력 장치들이 알아서 인식되는 등, 한번 Xorg에 큰 변화가 이루어진 적이 있었는데, 이것이 바로 KMS가 있었기에 가능했던 것이지요. 아마도 KMS가 본격적으로 지원된 커널이 2.6.35버전부터 였을 것입니다. 아무튼 Xorg의 코드 사용은 점점 줄어가는데 정작 Xorg는 코드가 너무 방대해서 이 코드들을 줄일 방법이 전혀 없었습니다. 지금도 레거시 지원이라는 명목으로 예전 방식 그대로 설정을 하면 그대로 먹히기는 합니다만, 해상도 설정이나 입력장치 설정 같은 것은 굳이 예전방식으로 할 이유는 없다고 봅니다. KMS방식이 훨씬 빠르기도 하고 가볍기 때문이지요.

 Wayland는 이를 중점으로 삼고 기존의 X11이 사용하지 않거나 사용되지 않게 될 부분을 과감히 쳐내고 필요한 부분 만을 구현해서 만들어냅니다. 이를 통해서 훨씬 작은 시스템이 가능해지고, 가벼운 데스크탑 환경을 만들 수 있게 되었습니다. 실제로 Wayland는 Xorg의 1/10크기 정도라고 하네요.

3. Xorg는 이대로 사라질 것인가?

Xorg도 그렇고 Xfree86도 그렇고, 이 물건들은 자동차로 치면 거의 포니 수준입니다. 그런데 이 포니에 HUD장치를 달고, 내비게이션을 달고, 이것저것 장치를 주렁주렁 달려고 하다 보니, 자동차가 삐걱거리기 일쑤에 지금은 쓰지 않는 쓸데없는 것도 생기게 됩니다. 이미 낡은 자동차에 장치만 잔뜩 달면 기름도 많이 먹겠지요? 참 보는 사람도 답답할 지경입니다.

이런 차에 내비게이션 달고, ABS브레이크를 넣고, 아이팟 시스템을 달고, HID라이트를 달고... 그냥 차를 바꾸는 것이 낫지 않을까? 사진은 현대 포니 출처 - 위키피디아

분명히 지금 사용하는 X11기반 프로그램들도 Wayland로 포팅될 것은 확실해 보입니다. KDE나 Gnome같은 메이저 데스크탑 환경도 Wayland로 포팅중이고 QT5기반의 새로운 Wayland기반 데스크탑 환경도 니왔습니다. (이름은 Hawaii입니다. MAUI프로젝트에서 진행 중입니다. (http://www.maui-project.org/) 그런데 Wayland로 넘어가기 위해 우리는 어떻게 해야 할까요? 사실 우리는 Wayland가 나왔다고 무조건 바꿀 수 있는 상황이 안 됩니다. Wayland만으로는 인터넷조차 하기 버거운 상황이거든요. Firefox가 Wayland기반이 아니라 여전히 X11을 이용하기 때문에 간단한 인터넷도 현재 Wayland만으로는 부족합니다. Firefox나 Chrome도 결국에는 X11기반이 아닌 다른 물건으로 바뀌겠지만, 그것이 Wayland가 될지 아니면 다른 프로젝트의 결과물(Mir같은...)이 될지는 아무도 모릅니다. 그 때쯤이면 Xorg는 추억속의 물건이 될지도 모르겠습니다.

4. Wayland를 지금 써보고 싶다면?

현재 Wayland는 그럭저럭 쓸만한 수준까지 만들어져 있습니다. 그런데 이를 제대로 활용한 배포판이 많지가 않습니다. Debian에 Wayland는 있지만 Debian이 그렇듯이 검증 안 된 패키지는 저장소에 잘 안 들어가게 됩니다. 따라서 Debian은 Wayland를 이용하기 좀 어려운 배포판입니다.(물론  Unstable이나 Sid를 이용하면 되기는 합니다.) Wayland를 써보시겠다면 ArchLinux로 써보시길 추천드립니다. Wayland같이 안정 버전이 없거나, 검증되지 않은 패키지는 빠른 업데이트가 제일 중요한데 Arch같이 빠른 업데이트를 지원하는 배포판은 없기 때문입니다. 게다가 다른 배포판(Debian계열이나 Ubuntu계열이 대표적으로)은 wayland 패키지를 설치했어도 xorg패키지를 설치하지 않으면 GUI설정이 전혀 안되거나 스크립트를 이리저리 뜯어야 하는 문제가 있지만, Arch는 원래 GUI부터 수동이라 Wayland설정을 하기가 더 쉽습니다. 위에서 말한 MAUI프로젝트도 Arch기반인 것도 다 이유가 있는 것이지요. https://wiki.archlinux.org/index.php/wayland 여기의 내용을 그대로 따라하시면 Wayland 기반의 Arch환경을 구축 하실 수 있습니다. 여기에 X호환환경을 만들어주는(사실 Wayland내에 Xorg를 올리는 형태지만) Xwayland를 갖춰주시면 지금도 쓸만한 데스크탑환경이 됩니다.(Xwayland를 이용함으로써 X11기반 프로그램도 쓸 수 있습니다.)

 반대로 Xorg환경내에서 wayland를 이용하고 싶으시다면 기존의 X11기반의 배포판에 wayland를 설치만 해주시면 weston 명령으로 wayland를 창 형태로 돌려보실 수 있습니다.다만, wayland전용의 환경은 많지 않아서 말 그대로 테스트 그 이상의 효과는 못 낼 것 같습니다. 하지만 X11용 그래픽드라이버를 이용하면서 가속도 할 수 있으니, nvidia나 따끈따끈한 신형 AMD GPU 이용자(Catalyst만이 해답인..)라면 이걸로 쓸 수 밖에 없을 것입니다. Wayland는 오로지 오픈소스 드라이버만이 사용 가능하니까요.

5. 잠깐 Xwayland라고요?

위에서 저는 언젠가는 X11기반 프로그램들이 Wayland 기반으로 포팅 될 것이라고 했습니다. 하지만, 사실 Wayland는 X11호환을 위한 라이브러리가 준비 되어있습니다. 제가 Xorg환경내에서 weston명령을 쓰면 새 X11창 내에 Wayland 환경이 뜬다고 했지요? 그걸 반대로 뒤집으면 된다고 생각하면 됩니다. Wayland환경내에 X11환경을 띄우는 것입니다. OSX도 비슷한 짓을 하니까(X11을 내부에서 돌립니다.) X11자체는 크게 패치를 할 것이 없을겁니다. 이 것을 이용하면 Wayland로 포팅이 이루어지지 않은 프로그램도 쉽게 쓸 수 있게됩니다. 예를 들면 지금의 유료프로그램을 들 수 있겠네요. Matlab이라든가, 한글2008같은 프로그램 것 말이지요. 특히 한글은 wayland로 포팅 될 일이 없을 테니 꼭 필요해 보입니다. 그런 프로그램들을 위해 Xwayland가 준비 되었는데, X11이 완전히 사라지게 되면 Wayland내에서도 바로 내 쳐질 것입니다. 어차피 호환을 위해 만들어진 기능이니까요. 하지만 X11이 30년동안 쓰여오면서 그 기반 프로그램을 무시 못하니 Xwayland가 만들어진 것입니다. 30년 동안 쓰인 GUI서버가 언제쯤 사라지게 될지는 알 수 없지만, 그 때까지 부족한 Wayland기반 프로그램들을 대신해줄 물건임에는 틀림 없습니다.

6. Wayland외의 또 다른 경쟁자는?

 과거의 X11을 대체하기 위해 만들어진 프로젝트는 많았습니다. 그나마 뚜렷한 성과를 보인 것은 XGL(OpenGL기반 X11대체 프로젝트)이 있었습니다. 하지만 이도 AIGLX(X11 개선에 초점)에 의해 밀렸고, 지금까지도 X11이 쓰이게 됩니다. 즉, Wayland같이 이렇게 가시적인 성과를 보인 프로젝트는 거의 없었던 것이지요. 딱 하나만 제외하고요. 우분투를 만들어서 배포하는 캐노니컬의 Mir가 현재로써는 유일한 경쟁자로 보입니다. Mir가 어떻게 나올지 어떤 모습을 하게 될지는 캐노니컬이 공개를 하지 않아서 알 수는 없지만, Wayland와 비슷한 형태가 될 것이라고 생각은 듭니다. 어쩌면 XGL vs AIGLX 때처럼 Mir vs Wayland가 될 가능성도 있겠지요. 어떤 프로젝트가 사라지게 될지 아니면 둘 다 살아남아서 서로의 장점을 이끌어낼지는 아무도 모릅니다. 하지만 Mir가 공개된 정보가 많지가 않아서 Wayland와 다르게 알 수가 없습니다. 지금 당장 사용해 볼 수도 없고 알 수도 없어서 아직까지는 Wayland가 대세라고 생각합니다. Mir는 이 Wayland를 뛰어넘어야만 세상에 공개 될 것 같습니다.

리눅스/유닉스는 X11을 통해서 GUI란 놈을 세상에 알렸습니다. 실제로 GUI를 제대로 퍼뜨린 것은 Apple이지만, GUI의 개념을 제대로 만들어 낸 최초의 결과물은 X11이었지요. 이제 그 X11이 역사속으로 사라질 준비를 하고 있습니다. 다만, 역사속으로 사라지려면 좀 시간이 많이 걸릴 것 같네요. 과연 Wayland가 성공적으로 안착을 할 수 있을까요? Xorg는 역사 속으로 사라질 수 있을까요? 리눅스/유닉스의 GUI는 또 어떻게 바뀔까요? 모바일 시대로 넘어가는 이 때의 Wayland가 모바일 시대에 맞춰서 나올 수 있을까요? 10년 뒤의 모습이 정말 궁금합니다.

2016. 3. 23 추가

2016년이 되고보니 Mir도 공개되고 Wayland와 맞붙을 준비가 되었습니다. 아직 Mir가 지원하는 환경이 많지는 않지만 Wayland가 지금까지 걸어온 길에 비해 상당히 순항을 한 것으로 보입니다. 특히 이제는 Unity가 불편한 UI가 아닌 빠릿하고 편리한 UI라는 평가를 받는 지금 Mir가 Wayland에 비해 이득이 더 클 것으로 보입니다. 아쉬운 것은 Wayland가 아직까지도 안정화가 안 되었다는 사실입니다. Mir는 이제 16.04에 탑재 되는 것으로 잠정 결론이 났는데(15.10에서 설치가 가능합니다.)Wayland는 아직까지도 안정화가 되었다는 느낌이 없습니다.

이렇게 가다가는 Wayland를 10년뒤에나 제대로 볼 수 있을지도 잘 모르겠습니다.

리눅스를 다른 사람들에게 별로 추천하지 못하는 이유 중 하나가 응용프로그램, 그 중에서도 게임이 안 된다는 것이 주 원인입니다. 우분투 8.04 시절에 Compiz의 화려한 효과를 보여주면 사람들은 우와~ 했지만 언제나 돌아오는 질문은 "근데 이거 게임 되냐?"였습니다. 그 당시에 제가 할 수 있던 대답은 하나였지요.

"스타 정도는 삽질하면 돌아가."

네 삽질 좀 해야 스타가 돌아가던 시절이었습니다. 물론 스타가 돌아간다는 사실 만으로도 행복하던 시절이기도 했지요. 물론 리눅스용 게임으로 퀘이크가 있기는 했지만 지금이나 그때나 퀘이크는 아는 사람만 아는 게임이었습니다. 퀘이크라고 해봐야 "그게 뭔데?"라는 질문만 돌아올 정도였으니 예시로 들기에는 부적절했습니다. 그래서 하는 수 없이 그 당시에도 꾸준한 인기가 있었던 스타크래프트를 예로들었지요.이후에 Wine이 꾸준히 개발되며 호환성을 상당히 확보했고 표준 Windows API가 아닌 특이한 방법으로 만들어진 게임이 아닌 이상 어쨌건 게임이 되긴 되는 시대까지 되었습니다. Wine이 거의 완벽한 호환성을 갖추게 된 때가 아마도 2009~2010년이 되었을 때였을 것입니다.

그리하여 Wine을 이용해서 수많은 윈도용 게임을 리눅스에서 할 수 있게 되었습니다. 물론 패키지게임의 경우 DRM들이 문제를 왕창 일으키기는 했지만 No-CD, No-DVD 패치들이 인터넷에 돌아다녔기 때문에 보통 이를 이용해서 해결했습니다.

우분투 10.04시절 롤러코스터 타이쿤3 구동 스크린샷 저의 Daum블로그에 올렸던 스크린샷입니다. 그래픽은 기본 wine으로 구동 음악은 DirectX9 라이브러리 설치후 설정으로 해결

어쨌건 이제 리눅스에서 게임이 안 된다는 말은 옛말이된지 오래되었습니다. 다만 Wine을 이용한 방법은 생각 외로 복잡해서 설치하는 사람에게 고통을 자주 안겨주었습니다. 그 때 해결 방안을 함께 알려준 물건이 바로 PlayonLinux입니다.(http://www.playonlinux.com) 이전에도 포스팅을 했었지만 PlayonLinux는 Wine만으로 게임하기가 너무 불편하고 힘들자 Wine을 버전별로 관리하게 하고 각 프로그램마다 가상 윈도(즉, Wine의 FakeWindows를 말합니다.)설정을 다르게 해서 게임 별로 관리하기 쉽게 만든 것이 특징입니다. 지금은 게임 외의 다른 프로그램도 지원하지만요.

무엇보다 게임설치에 필요한 라이브러리(DirectX같은 것을 말하는 것입니다.)를 자동으로 미리 설치해주고 설치를 쉽게 하도록 안내해주고 있어서 이 프로그램을 이용하면서 리눅스에서의 윈도 게임은 쉽고 빠르게 즐길 수 있게 됩니다. 사실 PlayonLinux 이전에도 Wine을 편하게 쓰기 위해서 많은 시도가 이루어져 왔습니다. Wine-doors라던가 Cedega(이것은 자체 개발한 유료 라이브러리인 WineX라는 것을 이용합니다.)라던가 많이 있었지만 PlayonLinux와 Cedega와의 차이는 사용 라이브러리가 Wine이냐 WineX냐의 차이였고 Wine-doors는 그냥 Wine을 GUI로 쓰고자 하는 경우에 가까웠습니다. winetricks(https://code.google.com/p/winetricks/)를 통해 라이브러리르 설치하는 것도 물론 없었고요. PlayonLinux의 설치스크립트 같은 것은 없었습니다. PlayonLinux가 지금은 게임 만큼이나 다른 일반 프로그램설치도 지원하지만 지금도 게임이 제일 많이 리스트에 있습니다. 그것이 사실 처음에는 게임에 특화 시켰던 흔적 이라고도 볼 수 있습니다. 

하지만 PlayonLinux는 모든 게임을 자동으로 완벽하게 해주지는 못했습니다. 바로 No-CD,DVD패치가 법적인 문제가 있어서 이용자가 따로 패치를 하도록 구성을 할 수밖에 없었기 때문입니다. "패치만 해주면 되는데 상관없지 않나?"라고 생각하시는 분들도 있을 수 있는데 처음 쓰는 사람에게는 그것도 은근히 고역입니다. 게다가 No-CD,DVD패치를 구글링 해야하는 수고도 필요했고요. 그런데 이때 DRM-FREE를 표방한 사이트가 등장하게 됩니다. 바로 GOG.com입니다. 이 GOG.com에서 파는 게임들은 따로 패치를 하는 수고로움이 없어졌기에 PlayonLinux에 리스트업됩니다. 이 때 상당히 업데이트가 잦았던 것으로 기억합니다. GOG.com에 새로운 게임이 올라오면 그 순간 새 설치리스트가 올라올 정도였습니다.

DRM-FREE게임을 판매하는 GOG.com 이제는 윈도용 뿐만 아니라 리눅스게임도 팔고 있습니다.

이제 리눅스에서는 Wine의 힘을 얻고 윈도용으로 출시된 게임들을 할 수 있게 되었습니다. 하지만 인간의 욕심은 끝이 없지요. 컴퓨터의 최고 성능을 끌어내야 하는 게임에서 Wine을 한번 거쳐야 한다는 사실은 게임에게는 좀 부족했었던 것 같습니다. 특히 네이티브 리눅스 지원게임과 윈도게임을 Wine으로 돌리는 것은 정말 큰 차이가 났습니다. 이후로 리눅서들은 리눅스 네이티브 게임을 갈망했는데 이를 한번에 뚫어준 것은 다름 아닌 세계 최대 게임유통사(?) Valve였습니다.

스팀에서 팔고있는 리눅스 지원 게임들 자그마치 600여개가 넘어간다. 그 중에서 문명5도 포함되어져 있다.

Valve는 아시는 대로 Steam이란 거대 유통망을 가지고 있는 회사입니다. 그리고 PlayonLinux에 따로 Steam이 있을 정도로 Steam을 이용한 게임을 돌리기 위한 노력도 정말 많이 있었습니다. 그런데 어느날 Valve는 Mac용 Steam을 발표하면서 FAQ부분에 의미심장한 부분이 추가되게 됩니다.

Q : Linux용은 없나요?

A : 아직 Linux용은 개발되지 않았습니다. 하지만 Wine을 이용해서 Windows용 Steam을 실행해 볼 수 있습니다.

정말 이렇게 나와있었습니다. 아마도 Mac용이 출시 된다고 했을 때 Linux용에 대한 문의가 많았던 것 같습니다. 그래서인지 Wine으로 실행이 가능하다고 친절(?)하게 답을 달아주었습니다. 실제로 이 때 Wine으로 Valve사 게임은 충분히 돌아갔으므로 틀린 말은 아니었지요. 하지만 이 일이 기폭제가 되었을지는 잘 모르겠습니다. 어느날 Valve는 갑자기 Linux용 Left4Dead2를 시연하면서 Linux용 Steam을 발표하게 됩니다. Steam의 전부는 아니지만 Steam의 이용 목적이라고 할 수 있던 Valve사의 게임을 Linux로 포팅 하겠다는 발표도 빼놓지 않았습니다. 리눅스 커뮤니티는 전부 뒤집어졌습니다. 어떤 분은 이런 글을 남기셨더군요.

"Valve가 리눅스로 도망간 내 지갑을 또 노리고 있다."

어쨌건 이로써 Lefrt4Dead나 TeamFortress2 등의 굵직한 게임들이 리눅스 네이티브로 출시되게 되었습니다. 물론 리눅스용이 따로 있었던 게임들도 Steam을 통해서 리눅스용을 구입할 수 있게 되었습니다.

 사실 이렇게 되어버린 것도 시장경제논리에 따른 것입니다. 그 원인은 Microsoft가 만든 것이고요. 무슨 말이냐면 Microsoft가 WindowsStore를 Windows8에 끼워넣자 Valve는 Steam의 영향력이 줄어들 것이라 생각하고는 Windows외의 도피처를 생각하게 됩니다. 사실 Microsoft의 윈도 끼워넣기로 잘 나가던 회사가 망한 것이 한둘이 아님을 감안하면 충분히 예상은 가능했지요. 이 때 Valve가 생각한 것이 바로 리눅스였던 것입니다. MacOSX도 있지만 어차피 얘네도 앱스토어가 있어서 자신들이 직접 게임을 팔겠다고 나서기 충분한 상황이었습니다. 지금도 실제로 팔고 있고요. 그 다음 플랫폼은 바로 리눅스입니다. 점유율은 다른 OS에 비하면 박살이기는 했지만 충분히 경쟁력은 있다고 생각했음이 분명합니다. 어쨌건 Valve는 결국 리눅스 중에서도 특히 데스크탑용으로 많이 쓰이는 우분투 용으로 Steam은 출시되게 됩니다. 그리고 우분투 게이머들은 환호했구요. (물론 그들의 지갑은 가벼워졌다고 합니다.)

그런데 Valve는 Microsoft를 보면서 한 가지 더 생각한 것이 있었던 것 같습니다. Microsoft가 자신의 플랫폼을 가지고 시장을 좌지우지 한다고 판단한 것인지 Vavle는 리눅스를 기반으로 한 SteamOS를 발표하게 됩니다. 이미 자사 게임들을 리눅스 용으로 내놓았고 리눅스용 게임도 충분하니 이 SteamOS도 크게 꿀릴 것인 없다고 판단한 모양입니다. 아니면 Steam의 점유율을 새로운 플랫폼 창조로 잇겠다는 극히 Valve스러운 행보일 수도 있고요.

이 SteamOS는 리눅스를 기반으로 한 또 다른 OS이기도 하지만 오로지 Steam만을 위한 OS이기도 합니다. 사실 일반 적인 리눅스 데스크탑에 Steam을 설치한 것과는 크게 다르지 않습니다만 필요한 것만 설치하고 다른 것은 일체 배제함으로써 OS를 게임용으로 최적화를 가능케 한 면이 있지요.

그리고 이 SteamOS를 기반으로 소위 SteamBox란 것도 있고 터치패드를 이용한 Steam용 게임패드도 개발중에 있습니다. 즉, Steam을 이용해서 거실의 최강자 Microsoft와 Sony 그리고 Nintendo의 자리까지 노리겠다는 수로 보입니다. 어찌보면 Micorosoft에게 복수한 것이 아닐까 생각이 들 정도네요.

하지만 이 SteamOS의 성공을 판가름할 열쇠도 다름 아닌 리눅스용 게임들입니다. Valve는 WindowsPC에서 스트리밍해서 플레이 가능케 하겠다고 하는데 그래봐야 리눅스 네이티브 보다 성능이 떨어질 것은 뻔합니다. 다시 한번 말씀드리지만 게임이란 하드웨어의 성능을 제일 많이 필요로 하는 프로그램입니다. 스트리밍만으로 부족할 가능성이 높습니다. 무엇보다 아직까지도 스트리밍이 구현되었다는 소리를 못 들었습니다. 스트리밍의 성능이 어느정도 나올지는 일단 나와봐야 알 것 같고 현재 SteamOS에서 돌아가는 것은 오로지 리눅스용 게임들 뿐입니다. 이 게임 중에 킬러컨텐츠는 얼마나 있을까요? SteamOS가 성공하면 리눅스는 이제 게임하기 어려운 OS가 아니게 될 것입니다. 다른 프로그램을 몰라도 게임하나 만큼은 자신있는 플랫폼이 될 수도 있습니다. 제 나름대로는 이 SteamOS가 꼭 성공하기를 바랄뿐입니다.

제가 리눅스를 처음 접했던 시절에는 정말 게임하기 힘들었습니다. 아니 애초에 게임을 하려고 한 발상자체가 말이 안 되던 시절이기도 했지요. 그런데 이제 7년정도 지나가니 리눅스가 게임 전용 플랫폼이 되기도 하네요. 덕분에 요즘에는 몇몇 친구들 한정해서 우분투 써보라고 하기도 합니다. 왜냐하면 게임도 잘 돌아간다고 얘기해 줄 수 있거든요.