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

Docker는 이미 서버관리에서 필수가 된지 오래입니다.

https://www.docker.com

고래가 컨테이너들을 잔뜩 얹고 있는 이 모양은 바로 Docker가 나가고자 하는 방향을 나타냅니다. 

사실 Docker가 가지고 있는 가능성은 무궁무진합니다. 리눅스 컨테이너를 가상화하여 리눅스 프로그램을 정해진 환경에서 구동할 수 있게 만드는 것으로 특화 되어있습니다. 

이는 이미 우리나라에서 Docker에 대해 알고자 할 때 추천되는 바이블인 "가장 빨리 만나는 Docker"란 책에서도 나와있습니다. http://pyrasis.com/docker.html

그동안 서버를 구성하고자 하면 고생하는 것이 이만저만이 아니었습니다. 어떤 배포판은 /usr/lib에 서버가 설치되고 관리되면 어떤 배포판은 /usr/lib는 대몬만 설치되고 설정은 /etc로 관리됩니다. 또 어떤 배포판은 /usr/local에 설치됩니다. 제각각으로 관리되던 서버 설정 및 설치과정을 한큐에 해결하게 만든 것이 바로 docker입니다.

예를 들어 웹서버를 하나 구성하고자 한다고 하면 Nginx+PHP+MariaDB로 보통 구성됩니다. 그런데 배포판이나 OS마다 각 서버를 연동시키려면 고생이 이만저만이 아니었습니다. 어떤 배포판은 PHP를 CGI형태로 구동하고 어떤 배포판은 nginx로 하면 안 되고 Apache로 해야만 구동이 되는 등 중구난방이 따로 없었습니다. 10년 전에 Apache+Tomcat(JSP)을 하려고 할 때 서버를 뒤집어 엎어서 구성해야 가능했던 것을 생각하면 어휴...

하지만 Docker를 쓰면 미리 구성된 배포판과 서버 대몬이 그 어떤 리눅스 위에서도 문제없이 구동이 됩니다. 모든것이 완성 되어있기에 그냥 Docker 컨테이너를 올리는 것으로 서버 구성이 끝나게 됩니다. 그리고 그렇다는 것은 그동안 서버 관리자를 괴롭혔던 배포판별 판이한 구성 문제가 없다는 이야기가 됩니다.

사실 이전에 저도 비슷한 것을 구상하긴 했습니다. 다만 Docker같은 컨테이너가 아니라 VirtualBox를 이용한 돈없는 자를 위한 Sphere(VMware)를 구성했습니다. 성능은 당연히 VirtualBox이기에 영 아니었고 50%이상 성능이 까였기에 그냥 Sphere를 구입하는 것이 100배 나은 물건이었습니다. 장점은 VirtualBox라서 윈도우도 올리는 것이 가능했단 점 정도? 좋은 것은 하나도 없었습니다.

지금은 서버라면 다들 Docker로 구성해서 컨테이너를 올리는 것 만으로 서버구성을 끝내는 것이 대세입니다. 하지만 docker라는 이 녀석을 서버용으로만 사용하는 것이 좋을까요?

사실 저는 이미 Docker를 데스크탑에 적용해서 사용하는것을 블로그에 올린적이 있습니다.

http://moordev.tistory.com/180

의외로 방문율이 높은 포스트 중 하나이다. 이 글은 한글2008을 구동하는 것 뿐 아니라 원격 X프로토콜을 가지고 노는 기술도 포함되어 있다.

바로 한글2008을 배포판 관계없이 설치해서 사용하는 것을 docker를 써서 하는 것으로 만들었습니다.

즉, Docker를 서버만 쓰지 않고 데스크탑에도 적용해서 사용하단 것을 보여 드렸습니다. 

그냥 GUI를 Docker에서 굴리기 위해 만들어진 프로그램도 있습니다. X11Docker란 프로그램입니다.

https://github.com/mviereck/x11docker

이쪽은 그냥 데스크탑을 컨테이너화 해서 굴리는 것을 목표로 합니다. 그냥 다른 배포판을 쓰는 것이 가능합니다. 우분투에서 데비안을 혹은 페도라를 얼마든지 구동할 수 있다는 의미입니다. VirtualBox등을 통해 설치후 사용하는 것이 아닌 성능저하 거의 없는 가상화 리눅스를 그냥 얻어 내는 것입니다. 특히 몇몇 프로그램의 경우 라이브러리를 맞춰준다던지 파일 경로를 만들어서 묶어준다던지 해야하는 경우가 많은데 이렇게 하면 리눅스 데스크탑도 Docker를 통해 삽질 없이 바로 사용가능하게 만들 수 있다는 의미가 됩니다.

사실 저 X11Docker는 제가 유심히 보고 있는 프로젝트입니다. 엄청 유용할 것으로 예상되는데다가 32비트 우분투의 배포가 중단되고 있는 지금 구형 프로그램을 굴려야 할 때 굳이 오래된 우분투를 설치하지 않고도 최신 배포판에서 구형 프로그램을 굴릴 수 있게 하는 아주 좋은 프로젝트라고 생각하고 있습니다. Wine 1.0이라던가 한글2008이라던가 혹은 MATLAB 구형같은 오래된 프로그램이 있을 수 있겠지요!

그렇게 쓰다가 조금 시스템이 꼬인다 싶으면 그냥 컨테이너를 내렸다가 다시 올리면 됩니다. 참 쉽죠?

Docker를 굴리는 방법에 대한 이야기는 아까 말한 가장 빨리 만나는 Docker를 추천하고 저는 Docker를 다른 방법으로 사용하는 것에 대해 말씀드렸습니다. Docker를 서버외의 용도로도 쓸 수 있다는 것을 알아 주셨으면 좋겠습니다.

우분투 관련 이야기지만 우분투 분투기가 아닌 리눅스 관련 이야기로 올립니다.

우분투 18.04의 정식판 공개일이 코앞으로 다가왔습니다.

이번 우분투 18.04는 기존 우분투 16.04LTS에서 4.15 커널과 그놈 환경 이용 등으로 획기적인 변화를 가져올 예정입니다. 다만, 기존 16.04가 처음 나왔을 때 호환문제로 고생을 한 기억이 있어서 바로 18.04로 넘어가는 것은 조금 무리가 있다는 판단이 듭니다.

1. Wayland에서 다시 Xorg로 돌아가다.

이번에 18.04에서 생각해봐야 할 것은 17.10때 적용되었던 wayland의 적용을 뒤로 미뤘다는 것입니다. Wayland는 Xorg를 대체할 차세대 GUI서버로 작은 크기와 빠릿한 반응으로 기대를 받고 있습니다. 아니, 유망주로 몇년째 담금질을 하고 있습니다.

다만, 기존에 Xorg기반으로 만들어진 프로그램이 워낙 많고 Wayland의 호환레이어인 Xwayland가 완벽한 호환을 보여주지 못하고 있어서 17.10시절 고생을 한 사람이 많다고 하네요. 그래서 이번 18.04는 Wayland 대신 Xorg를 기본 서버로 되돌리고 옵션으로 Wayland를 쓸 수 있도록 했다고 합니다. 일단은 그래도 LTS니까 Wayland는 조금더 지켜보기로 한 것입니다. 아마도 Wayland로 전환되기까지는 사운드쪽의 OSS에서 ALSA로 넘어가던 시절만큼 시간이 오래걸리지 않을까 싶습니다.

2. 32비트 버전의 이미지 배포 중단

 이젠 32비트버전의 배포판을 더 이상 만들지 않겠다고 합니다. 하지만 32비트 라이브러리는 계속 지원을 할 것이라고 합니다. 아직은 32비트를 버릴 수는 없으니까요. (특히 Wine과 Windows의 32비트 프로그램, 그리고 일부 32비트용 게임 때문에 32비트는 어쩔 수 없습니다.)그러므로 아마도 리눅스민트나 다른 우분투 기반 OS에서는 32비트 버전이 나올 가능성이 높습니다. 특히 저사양PC의 재활용을 중점적으로 다루는 LXLE(http://lxle.net/)같은 경우에는 32비트 버전이 나오지 않으면 위치가 애매해집니다.

32비트 문제로 엑소더스가 일어나지는 않을지 지켜봐야 할 것 같습니다.

Windows의 경우 16비트에서 32비트로 넘어가기까지 꽤 걸렸던 것 같은데(32비트는 그 전부터 쓰이고 있었지만 WindowsMe를 마지막으로 16비트 코드가 사라지게 됩니다.) 32비트에서 64비트로 넘어가는 것은 더 오래걸리고 있어서 우분투가 먼저 선수를 치는 것 같네요.

생각해보니 64비트OS도 리눅스에서 먼저 나왔던 것을 생각하면 이해 못할 일은 아니라고 봅니다. (WindowsXP x64 2005년 출시, AMD64 리눅스 커널 2003년 릴리즈)

3. 커널 4.15의 적용

 이번에 각종 보안 이슈로 인하여 걱정이 이만저만이 아닌 사람들이 많습니다. 컴퓨터를 그냥 집에서 가지고 노는 용도로만 쓰거나 별 관심이 없는 사람들은 모르지만 멜트다운, 스펙터 버그로 인하여 업무용으로 사용하는 사람들은 걱정이 이만저만이 아니었습니다.

 그러한 버그를 해결한 커널이 4.15입니다. 물론 바닐라 커널 기준으로 4.15부터 패치가 적용되었지만 배포판 업체에 따라서 이전 커널에 백포트되어 적용이 되기도 합니다.(레드햇 같은 업체는 커널 3.x대와 함께 2.6도 아직 지원합니다.) 하지만 백포트는 어디까지나 백포트이고 메인 프로젝트는 리눅스재단의 커널이 만들고 있는데 이번 4.15부터 해당 버그해결과 사고를 일으킨 인텔의 ME를 걷어내는 작업까지 해 놓았습니다. 아마도 시스템 내부적으로 제일 큰 변화가 이것이 아닐까 싶습니다. 16.04에서도 바닐라 4.15를 쓰고 있는데 캐노니컬이 만드는 4.13보다 훨씬 낫습니다.

4. 데스크탑 리눅스의 기준

 이렇게 이야기하면 openSUSE나 Fedora를 쓰시는 분들이 쳐들어올 것 같은데 우분투는 데스크탑용 리눅스의 기준입니다.

 데스크탑에서 제일 중요한 것은 이용자의 편리함입니다. 흔히 UI를 이야기하지요. Gnome이 리눅스 데스크탑에서 주가 된 것은 사실 우분투의 영향이 컸다고 봅니다. 사실 우분투에서 Gnome이 제일 잘 돌아가기도 하고요. 게다가 Nvidia나 AMD는 자사의 클로즈소스 드라이버를 발표할 때 우분투 발표에 맞춰서 발표를 합니다. 이유는 리눅스 데스크탑 사용자들이 업그레이드하는 시기가 우분투 발표와 겹치기 때문입니다.

특히 우분투 LTS의 업그레이드는 이용자가 대거 업그레이드를 시도하는 시기이기 때문에 특히 드라이버를 만들 때 신경을 쓰게 됩니다. 지난 16.04발표후 Catalyst가 우분투 지원에서 내려가게 되었는데 대신 AMD는 AMDGPU-Pro라는 오픈소스를 기반으로 하되 클로즈 소스를 추가한(그러니까 오픈소스인 크로미움에 클로즈소스인 구글앱과, Flash를 추가한 크롬을 생각해보세요.)드라이버를 발표했습니다. 새로운 우분투가 어떤 변화를 가져올지 조금 지켜봐야 할 것입니다.

5. 수많은 우분투 변형판들

사실 우분투도 데비안의 변형판이고 리눅스의 계보를 따라가면 레드햇, 슬랙웨어, 데비안 이렇게 셋이라고 하지만 이젠 제 갈길 가기 시작해서 따로 놀기 시작한 우분투는 데비안과 구분을 지은지 꽤 지났습니다. 그 편리함 때문에 우분투를 기반으로 한 배포판은 상당히 많습니다. 우분투가 나온다고 하면 우분투 그 자체보다 변형판들을 기대하는 사람들이 훨씬 더 많습니다. 저도 사실은 Gnome3보다는 MATE를 선호하기 때문에 ubuntuMATE나 LinuxMint MATE를 기대하고 있습니다.

그런데 이번 18.04는 17.xx부터 편입 된 공식 변형판들의 LTS버전이 나오는 버전입니다. 공식 변형판들은 18.04라는 이름하에 우분투와 동시에 나오게 됩니다. 16.04와 비교해서 공식 변형판들이 상당히 많아졌습니다. 선택의 폭이 넓어졌다고 해야 할까요? 저는 LTS에 눌러앉는 경우가 많아서 17.xx는 써본적이 없습니다. 게다가 16.04가 꽤 잘 버텨준 덕에 계속 16.04를 고수해왔고요. 어쨌건 18.04가 나오면 18.04기반으로 업그레이드를 해야하는데 선택의 폭이 확실히 넓어진 것을 환영해야 할 듯 합니다.

(하지만 전 LinuxMint MATE로 그냥 갈 것 같습니다....)

우분투 18.04 Bionic Beaver를 기대하며... 이상 마치겠습니다.

P.S ubuntuMATE 18.04의 파이널 베타 버전을 써봤는데 베타인데도 상당히 안정적이었습니다. 물론 베타1때는 불안정해서 안되겠다 싶었는데 한 달 만에 안정화가 되었더군요. 18.04는 상당히 안정적인 버전이 될 것임을 예상합니다.

서울서체가 무엇인지는 다들 아실 겁니다.

서울시에서 만들어서 서울시 곳곳의 서체를 필요로 하는 곳에 쓰이는 글꼴입니다.

꽤 예쁘게 만들어졌고 생각보다 깔끔하게 표현되어서 많은 사람들이 애용하는 중입니다.

https://www.seoul.go.kr/v2012/seoul/symbol/font.html

나름 저작권을 밝히고 있는 서울서체 홈페이지 그런데 Open Font Lisense는 아니다.

바로 옆나라 일본에서도 한글이 필요한 부분에서 이미 사실상 국제표준(?)한글 폰트가 된 NotoSans나 나눔고딕이 아닌 서울남산체를 사용한다는 제보가 있었고 서울시가 아닌 다른 지자체에서도 이들을 사용한다고 할 정도로 인기가 상당히 있는 글꼴이 되겠습니다.

그런데 이건 인쇄나 영상매체, 웹 용 등으로 사용할 때 이야기고 서울서체를 포함해서 커스텀 OS를 배포할 때는 어떨까요?

글꼴 저작권에는 재배포권이라는 것이 있습니다. 오로지 특정한 곳에서만 글꼴을 받을 수 있으며 다른 곳에는 이용을 할 수 없게 만들어진 것을 말합니다.

http://www.bloter.net/archives/201916

여기에 보시면 서울 서체는 기기 임베디드용으로 사용 가능하다고 나와있습니다. 이 경우에는 기기나 프로그램에서 글꼴로 사용할 때를 말하는 것이지요.

임베디드는 일종의 OS니까 사용가능한 것일까요?

몰랐는데 해당 부분은 가능하다고 보고 있습니다. OS에 내장시켰다고 보면 나름 이해가 가거든요.

그렇다면 사용하기 쉽게 패키지화를 했다면 어떨까요? 예를 들면 우분투에서도 쉽게 설치할 수 있도록 DEB으로 패키지를 만들었다고 합시다.

이건 어떻게 되는 걸까요? 앱의 임베디드는 가능하다고 하는데 이렇게 만들면 이건 임베디드가 아니라 그냥 재배포가 될 것 같은데요.

여기서 골치가 아파지기 시작하더군요. 사실 서울서체는 우분투같은 리눅스에서도 상당히 좋은 글꼴입니다. 그런데 서울시청에서는 윈도용 TTF만 배포중이고 이렇게 되면 리눅스 사용자들은 수동으로 TTF를 설치해야만 합니다.

그래서 이걸 패키지로 만들어서 배포하면 편하겠다고 생각한건데 이러한 상황은 생각하지 못한 것인지 아니면 재배포권에 대한 이야기는 전혀 없더군요. 찾아보니 이걸 시청에 물어본 사람도 없습니다. OS에 포함하는 것은 임베디드로 처리가 가능하지만 패키지는 아무리 생각해봐도 답이 안 나오네요.

서울시청에 물어보려고 해도 편하게 사용할 수 있게 자동화하여 묶었다고 하면 알아들으려나요?

솔직히 이걸 알아듣게 설명하는 것도 골치가 아프네요.

역시 매번 뭔가 하려고 하면 이렇게 쉽지가 않습니다.

==========

서울 시청에 전화해본 결과...

해당 폰트는 무조건 서울시청에서만 배포하며 다른 곳에서 배포는 금지되어 있다고 합니다. 쉽게 말해서 사용은 하되 서울 서체를 직접적으로 배포하지 말라고 합니다.

그러니까 패키지화는 하면 안 되는 겁니다. 아쉽지만 패키지로 설치하는 것은 물건너갔고 대신 MS폰트처럼 자동 스크립트형태로 설치하게 만들어야겠네요.

https://gist.github.com/keeferrourke/d29bf364bd292c78cf774a5c37a791db

여기있는 스크립트를 일부 수정해서 만들어봐야겠습니다.

최근 월광보합이라는 게임기(?)가 절찬리에 판매중입니다.

사실 별건 아니고 조이스틱과 게임기가 합쳐져서 만들어진 일종의 합본팩+게임기입니다.

인터넷 조금만 검색해도 이곳 저곳에서 월광보합이라는 이름하에 팔리고 있다.

그런데 이 물건... 정체가 뭘까요?

사실은 중국에서 처음 만들어진 일종의 에뮬레이터+조이스틱입니다. (요즘은 국내에서도 만듭니다.) 본래는 Pandora Box라는 이름하에 오락실에 야금야금 퍼져있었는데요. 오락실 업주 입장에서도 기존 캐비닛은 하나의 게임만 돌릴 수 있지만 이 물건은 한 캐비닛에서 훨씬 더 많은 게임을 넣을 수 있고 손님 입장에서도 자기가 원하는 게임을 할 수 있다보니 기존의 캐비닛들을 밀어내고 그 자리에 하나씩은 있더군요.

그러다가 그것이 돈이 된다고 생각했는지 오락실 캐비닛에 들어가던 회로 기판을 가정용으로 조이스틱에다가 내장해서 판매하는 것이 위에 보이는 물건들입니다.

실제로 용산 전자상가나 테크노마트, 청계천 대림상가에서 쉽게 볼 수 있고 판매되고 있습니다.

http://www.nocutnews.co.kr/news/4930646

기사까지 났네요. 복고바람이라고 하는데 사실 복고바람 이전에 레트로 게임기의 수요는 꾸준했기에 크게 와닿지는 않는 기사입니다. (실제 청계천에서 네오지오 아케이드 기판을 사가는 사람이 아직 꽤 있습니다.)

그런데 이걸 왜 리눅스 관련에다가 넣을까요?

뭐... 눈치빠르신 분들은 아시겠지만 이 물건의 OS는 리눅스입니다. 아니 리눅스일 수밖에 없습니다. 그렇지 않고서는 이 가격이 나올 수가 없지요. 리눅스에 MAME(http://mamedev.org/)나 FinalBurn Alpha(https://www.fbalpha.com/)같은 에뮬레이터를 설치하고 AttractMode(http://attractmode.org/)같은 프론트엔드를 만들면 이런 월광보합OS를 만들 수 있습니다.

귀찮으면 RetroPie(https://retropie.org.uk/)나 Recalbox(https://www.recalbox.com/)같은 이미 잘 만들어진 OS도 있습니다. 그런데 이것이 리눅스라는 사실을 아는 사람은 거의 없는 것 같네요. DOS아니냐고 하는 사람도 있던데 DOS도 가능하긴 한데 굳이 21세기에 16비트 OS가 필요할까요?

월광보합외에도 뭔가 제대로 된 듯한 레트로가 나왔으니 바로 닌텐도에서 내놓은 NES미니와 SNES미니가 있습니다.

http://www.bodnara.co.kr/bbs/article.html?num=143131

https://www.nintendo.co.jp/corporate/release/en/2017/170627.html

20년이 넘는 세월 동안 작아져서 돌아온 SNES미니 출처: 닌텐도 공식 홈페이지

이 물건도 사실은 ARM+리눅스+자체제작 에뮬레이터로 구성되어 있습니다.

사실 마음먹으면 SNES나 NES를 원칩으로 만들어서 그냥 기판에 박아버릴 수도 있을 텐데 이렇게 한 이유가 이쪽이 더 싸게 먹히기 때문입니다.

ARM칩셋은 스마트폰부터 웹서버에까지 사용될 정도로 광범위하게 쓰이고 있고 여기에 올라가는 리눅스OS도 소스코드가 공개되어 있어서 사용하기가 편합니다.

OS사용에 따른 최적화? 제일 싸구려 칩셋이 SNES의 스펙은 이미 뛰어넘은지 오래라서 SNES 원기기보다 프레임이 더 화면 전환이 부드럽습니다.

요즘에는 이것이 리눅스라는 것을 10분 활용해서 다른 짓을 하려고 한다고 하더군요. Xorg를 올리고 Gimp같은 데스크탑용 프로그램을 돌린다거나 기존 리눅스용 게임을 포팅해서 넣는다거나 하려고 한다고 합니다.

실제로 리눅스의 세계정복이라는 우스개 소리가 있는데 이런 식으로 알게모르게 야금야금 시장을 먹고 정복을 하고 있습니다.

보통 월광보합은 오락실 캐비닛을 위해 만들어진 만큼 오락실 게임위주로 되어있지만 에뮬레이터 특성상 꼭 오락실 게임만 들어갈 이유는 없지요. NES나 SNES, SEGA게임도 가능합니다. 이도 역시 리눅스이기에 가능한 것입니다. 조금 찾아보니 리눅스라는 십분 활용해서 NES 미니에서 Doom을 돌린 사람도 있다고 하네요.

https://www.ns-koubou.com/blog/2016/11/17/doom_on_nes_classic/

리눅스는 게임용으로 쓸 수 없다는 편견을 아직 사람이 아직도 많은데요. 제가 게임을 돌리는 방법을 자주 올리고 성공 사례에 리눅스용 게임들도 알려줘도 이해를 못하는 사람이 많더군요.

그런데 월광보합+Pump it up!+세가린드버그(이니셜D에 주로 쓰임)만으로 국내 오락실 지분 50%정도는 리눅스가 먹은 듯 합니다. (나머지는 철권이나 EZ2AC같은 Windows기반 기판과 아직 남은 자체 기판 정도일 겁니다.)

그.렇.다.는.것.은?

마음만 먹으면 월광보합같은 것을 만드는 것이 어렵지 않다는 것을 의미하기도 합니다. 어차피 리눅스고 리눅스가 돌아가는 곳에 조이스틱만 달아주면 월광보합은 만들 수가 있다는 의미가 됩니다. 제일 큰 문제는 게임 Rom을 어떻게 처리하냐가 문제입니다. 리눅스는 ARM에도 돌아가고 x86에도 돌아갑니다. 중고PC를 하나 구한다음 PC의 크기를 최소화 해서 쑤셔넣어도 되고 라즈베리파이 같은 저렴한 손바닥PC를 써도 됩니다.

그리고 오락실 버튼과 조이스틱을 사다가 달아주면 하드웨어 준비 끝. (버튼이나 조이스틱은 어디서 구하냐는 분들도 있을 텐데 청계천의 삼덕사에 가보세요. 우리나라의 어지간한 스틱은 이곳의 물건을 쓸 겁니다.)

나머지는 OS를 설치하고 에뮬레이터 설정 후 게임ROM을 넣어서 돌리는 것만 남은 것이지요. 참 쉽죠?

그렇기에 월광보합의 가격을 보면 결국 하드웨어 값만 들어있다는 결론이 나옵니다.(그 안에 있는 게임ROM들은 중국 물건 특성상 라이센스 했을리가 없습니다. 국내 제작은 본인이 게임을 넣도록 하는 경우가 많고요.)

그러므로 게임수가 많아서 가격이 비싸다느니 소프트웨어 최적화가 어쩌고 해서 가격이 높다라니 하는 것은 무시해도 됩니다. 그거 다 개소리에요. 오픈소스인 리눅스 커널에 오픈소스인 에뮬레이터를 깔고 소프트웨어라곤 프론트엔드인데 그 마저도 AttractMode같은 것을 썼다면 이것마저 무료. 게임ROM? 간혹보면 해킹판 롬도 있던데 원 게임사에서 그런 것을 허락했을리가...

아시겠죠? 그냥 좋다고 막 살 물건은 아니에요. 이 물건...

그냥 뭐.. 그렇다고요.

어떤 사람들은 "이게 무슨 소리야?" 하실 수도 있고

어떤 사람들은 "얘가 또 잘못 먹었나?" 하실 수도 있을겁니다.

아무래도 이쪽 계통의 사람들이라면 당연하게도 잘 알고 계실 겁니다.

안드로이드는 리눅스가 맞습니다.

그런데 리눅스의 정의가 무엇일까요?

이를 위해서는 OS의 정의부터 알아봐야 할 것 같습니다.

사실 세계 3대 OS하면 다음과 같습니다.

1. Windows

2. macOS

3. Linux

그런데 이렇게 나누는 것이 과연 정답일까요? OS가 필요한 이유가 무엇일까요?

이렇게 되면 복잡해지기 시작합니다.

간단하게 이야기해보겠습니다.

자동차가 있습니다. 자동차에서 제일 중요한 것은 보통 엔진이라고 합니다. 사실 엔진이 없으면 그저 동력이 없는 깡통일 뿐이니까요. 하지만 엔진만 있다고 자동차라고 할 수 있을까요? 멀리 갈 것도 없이 바퀴가 없으면 자동차로서 쓸 수 없는 물건이 됩니다. 거기에 사람이 앉을 수 있는 좌석도 있어야 하고 핸들과 같은 조작계도 있어야 합니다.

비슷하게 말하겠습니다.

여기 OS가 있습니다. OS애서 제일 중요한 것은 보통 커널이라고 합니다. 사실 커널이 없으면 그저 하드웨어를 쓸 수 없는 코드 덩어리일 뿐이니까요. 하지만 커널만 있다고 OS라고 할 수 있을까요? 멀리 갈 것도 없이 응용프로그램이 없으면 OS로서 쓸 수 없는 물건이 됩니다. 거기에 명령어체계도 있어야 하고 CLI나 GUI같은 인터페이스도 있어야 합니다.

위의 글과 아래글의 차이는 무엇일까요? 사실 저는 OS를 자동차에 비유했습니다.

즉, OS란 커널과 그 위에서 돌아가는 응용프로그램들과 인터페이스 등으로 구성된 것을 의미합니다.

그럼 리눅스의 정의로 다시 돌아와 보겠습니다.

우리가 흔히 리눅스라고 말하는 것은 어떤 것일까요? 제일 많이 쓰이는 우분투 리눅스에 대해 알아보도록 합시다.

우분투 리눅스는 당연히 리눅스 커널을 사용합니다.

인터페이스는 GUI로 X11기반의 Gnome(사람에 따라서는 Wayland가 기본)을 씁니다.

기본 응용프로그램으로 Bash를 쉘프로그램을 쓰고 Firefox를 기본 웹브라우저로 사용합니다.

일단 여기까지만 이야기 해봅시다. 이제 다시 확인 해봅시다. OS는 커널과 그 위에서 돌아가는 응용프로그램, 그리고 인터페이스 등으로 구성되었다고 했습니다.

우분투 리눅스는 리눅스가 맞습니다. 

그리고 서버용으로 쓰이는 RHEL도 리눅스커널을 쓰고 CLI로 Bash를 쓰면서 YUM이나 VI같은 응용프로그램을 씁니다. 그리고 RHEL도 리눅스가 맞지요.

보통 리눅스라고 부르는 OS는 이런 식으로 구성되었다고 생각하시면 되겠습니다. (서버용의 인터페이스는 Gnome이 아닌 그냥 콘솔 인터페이스라고 하지요.)

그럼 같은 Gnome 인터페이스를 쓰고 Firefox를 쓰는 FreeBSD는 무엇일까요?

우분투와 FreeBSD의 차이는 커널의 차이입니다.

우분투는 리눅스고 FreeBSD는 BSD입니다.

즉, 리눅스의 정의는

리눅스 커널을 사용한 OS라고 할 수 있겠습니다.

인터페이스가 무엇이든 응용프로그램이 무엇이든 그건 상관 없는 셈입니다.

그렇게 따지면 안드로이드는 분명 리눅스가 맞습니다.

하지만... 우리가 알고 있는 리눅스랑 사용 방법이 완전히 다릅니다.

왜냐하면 인터페이스가 완전히 다르고 전혀 다른 응용프로그램을 사용하니까요.

이렇게 생각해봅시다.

페도라와 우분투는 같은 OS인가?

같은 OS라고 보는 사람은 없을 겁니다. 일부 응용프로그램이 다르거든요.

(YUM, APT 등)

하지만 인터페이스는 같을 수 있습니다.

그리고 일정 부분 사용하는 응용프로그램이 같지요.

그럼 안드로이드는 어떨까요?

전혀 다른 인터페이스와 전혀 다른 응용프로그램으로 구성되어 있습니다.

즉, 안드로이드는 리눅스는 맞으나 다른 리눅스OS와 다른 OS라고 볼 수 있습니다.

그러니까 리눅스는 맞는데 우리가 흔히 말하는 리눅스와는 다른 물건이라고 할 수 있습니다. ChromeOS도 마찬가지입니다. 이것도 리눅스 커널을 썼으니 리눅스가 맞기는 한데 인터페이스도 다르고 응용프로그램도 제한적입니다. 그러니까 다른 OS로 봐야합니다.

이제 여기서 한가지 의문이 생기게 됩니다.

아까 3대 OS 이야기 했었지요?

1. Windows

2. macOC

3. Linux <-여기에 안드로이드가 들어갈까요?

정답부터 말씀드리자면 아니지요.

저 3대 OS란 표현부터가 틀려먹었습니다.

3대 데스크톱 OS라고 표현해야 합니다. 그런데 이것도 이상합니다. Linux란 것은 리눅스커널을 쓴 수많은 OS를 포괄해서 표현하는 것이니까요. 그럼 이렇게 다시 써야 겠네요.

1. Windows

2. macOS

3. Ubuntu

4. Fedora

이렇게 쓰면... 다른 OS사용자분들이 태클을 걸 것입니다.

1. Windows

2. macOS

3. Ubuntu

4. Fedora

5. OpenSUSE

6. Debian

7. Arch

...

...

...

에라이...

안드로이드 때문에 복잡해져 버렸네요.

그냥 이렇게 생각합시다.

안드로이드는 리눅스가 맞다 하지만 리눅스 데스크톱 OS는 아니다.

하지만 안드로이드가 데스크톱으로 들어오는 것도 머지 않았다는 사실...

RemixOS같은 물건이 존재하는 한 이것도 가능한 이야기입니다.

이러면 또 정의가 바뀌어야겠네요...

리눅스는 알다시피 게임용으로 쓰이기가 어렵습니다. 현존하는 대다수 PC게임들이 Windows용으로 나오고 있기 때문이지요. 하지만 SteamOS가 발표된 이후 메이저 게임업체에서는 자신들의 게임을 Linux용으로 포팅하기 시작했습니다.

그런데 과연 리눅스는 게임용으로 좋은OS일까요? 사회적인 이유는 집어치고 기술적인 이야기만 조금 하려고 합니다. 따라서 이번에도 글만 주루룩 나오겠군요.

1. Linux Gaming의 발목을 잡는 문제아. VGA Driver

PC게임에서 제일 중요한 부품은 무엇일까요? 대부분 사람들은 여기서 그래픽카드(VGA)를 생각하실 것이라고 생각합니다. 실제로 게임용 PC에서 제일 중요하게 여기는 것은 GPU의 성능입니다. CPU의 성능도 상당히 중요하지만 현대에서는 그래픽옵션을 어디까지 올릴 수 있느냐를 제일 먼저 보는 것이 당연시 되었습니다.

2017년 현재 그래픽카드 칩셋을 설계하는 업체는 Nvidia, AMD, Intel 셋이라고 봐도 과언은 아닙니다. 이 중에서 Intel칩셋은 언제나 게임성능이 별로 좋지 않기로 정평이 나있지요. Nvidia는 Geforce시리즈로 AMD는 Radeon시리즈가 있으니 이쪽은 아무리 싸구려를 써도 기본은 하는 편이고요.

그런데 리눅스용 드라이버 지원문제는 이래저래 문제가 참 많습니다. Intel의 그래픽칩셋을 게임용으로 쓰는 경우는 드물테니 넘어가고 Nvidia나 AMD 둘 다 리눅스에 관해서는 참 뭐같지요.

Nvidia의 경우 리눅스 지원이 그래도 좋습니다.

"좋은데 뭐가 문제야?"라고 하실지도 모르겠지만 문제는 오로지 바이너리 형태로만 지원을 합니다. 사실 리눅스커널에 드라이버 지원을 넣고 싶어도 바이너리 형태이기 때문에 Nvidia의 드라이버는 내장할 수가 없습니다. 우분투도 설치후에 따로 Nvidia의 드라이버를 다운로드 받아 설치를 하게 되어있습니다.

이는 Nvidia의 정책 때문인 것으로 보입니다. 아직까지는 Nvidia가 리눅스 지원을 잘 해주고 있지만 만약 Nvidia가 갑자기 지원을 끊어 버리면 어떻게 될까요? 그동안 Nvidia칩을 쓰던 리눅스 유저들은 낙동강 오리알 신세가 되는 겁니다. 실제로 Adobe가 그러한 일을 했었지요.

이는 토발즈 형님께서도 달갑지 않게 생각하고 계시며 Nvidia가 욕을 먹는 계기가 되었습니다. 하지만 회사차원에서 지원을 해준덕에 상당히 드라이버 성능이 좋다는 것이 일장일단이 있는 것이겠지요.

AMD의 경우에는 까탈리스트(Catalyst)라 불리는 문제의 드라이버가 말썽을 참 많이 일으켰습니다. 하지만 Catalyst는 이제 우분투에서 지원을 하지 않습니다. 왜냐하면 오픈소스 드라이버의 성능이 상당히 좋아져서 굳이 버그많고 시스템을 자주 사살하는 까탈스러운 녀석을 쓸 이유가 없어졌거든요. 대신 Catalyst가 지원되던 시절의 성능은 나오고 있지 않습니다. 대략적으로 약 80%정도 나온다고 하네요.

하지만 1프레임에 목숨을 거는 하드코어 게이머라면 20%성능조차도 끌어올리고 싶을 겁니다. 하지만 우분투 16.04이후 Catalyst는 정식 지원이 되지 않으므로 이를 설치했을 때 이전보다 더 큰 문제가 일어날 가능성이 높습니다. 아니, 정식지원 시절에도 문제가 많아서 열받았던 사람이 한 둘이 아닙니다! (대표적으로 제가 있습니다.)

AMD의 Radeon은 사실 Ati시절부터 자신들의 드라이버가 문제가 많았다는 것을 알았기에 이런저런 정책을 폈는데 그 중 하나가 자신들의 칩셋에 관한 문서를 오픈소스 커뮤니티에 제공을 하는 것이었습니다. 사실 지금의 오픈소스 드라이버 성능을 낼 수 있게 된 것이 바로 이 문서들 덕분이라고 해도 과언은 아닙니다. 그리고 KMS(Kernel Mode Setting - 커널이 VGA세팅을 직접 할 수 있게 한 기능)의 초창기 시절 Intel보다 Radeon을 먼저 KMS지원을 할 수 있게 도와주었습니다. 덕분에 이미지는 많이 좋아졌습니다. 하지만 예전에 당했던 상처가 아물기까지 아직도 세월이 많이 흘러야겠다는 생각이 듭니다.

표로 정리하면 이렇게 되겠네요.

리눅스에서의 게이밍용 GPU 비교

뭐... 그냥 제 마음대로 정리 한 것이니 넘어갑시다.

2. CPU의 지원?

요즘에 나오는 CPU는 전부 멀티 코어로 구성되어 있습니다. 따라서 요즘에 나오는 게임은 멀티스레드를 기본적으로 어느정도 만들어서 굴리게 되어있습니다. 그런데 멀티코어 프로그래밍이라는 것이 그렇게 쉽게 만들어지는 것이 아닙니다. 아무리 숙련된 프로그래머라고 해도 만약 시스템에서 이를 받아주질 못하면 말짱 꽝이라는 의미입니다.

Windows가 멀티스레드를 제대로 지원한 운영체제가 아마 WindowsXP SP1부터라고 기억하고 있습니다. 물론 서버용인 Windows 2000도 가능은 했다고 하지만 일반인이 서버용을 썼을리는 만무합니다. 하지만 WindowsXP SP3를 쓰더라도 현재 Windows7 이후의 멀티코어 성능보다 훨씬 더 효율이 떨어집니다. 왜냐하면 코어에 프로세스를 할당하는 알고리즘 자체가 최적화가 덜 되었거든요.

그럼 리눅스는 어떨까요? 사실 리눅스는 애초에 서버용으로 쓰였기에 멀티코어에 대한 준비는 어느정도 되어있었습니다. 다만, 이쪽도 완벽하지는 않았기 때문에 커널 2.6 시절에는 멀티코어 시스템에서 일부 싱글코어 프로그램을 돌리면 커널이 프로세스를 한 코어에 할당하는 것이 아니라 이 코어에 넣었다가 저 코어에 넣었다가 하는 삽질을 동원했었습니다. 그러니까 멀티코어를 쓰려고 하다보니 도리어 효율이 이상해지는 효과를 보았던 것이지요. (일종의 버그였습니다.)

현재는 커널에서 CPU에 대한 대응을 했기에 그런 일이 일어나지는 않지만 언제 다시 그런 버그가 벌어질지는 아무도 모릅니다. 실제로 AMD의 Ryzen의 경우 커널에서 바로 대응을 못해서 한 달 뒤에나 제대로 쓸 수 있게 되었습니다. 멀티코어 프로그램에서 이상 작동이 많았다고 합니다. 이 멀티코어 프로그램에는 커널도 포함합니다. 즉, 커널 패닉을 불러왔다는 것이지요.

리눅스용 게임의 경우 이러한 시스템적 이해가 없으면 문제를 일으키기 십상입니다. 효율이 떨어지는 발적화가 나오기도 하고 일부 시스템에서는 구동 자체가 안 되기도 합니다. 하지만 아직도 개발사들은 리눅스에 대한 이해도가 그렇게 좋지는 않은 것으로 보입니다. 대형 개발사의 게임은 상당한 최적화를 보이지만 개발환경이 열악한 인디게임에서는 상당한 발적화가 보입니다. 

3. 비표준 ACPI 전원관리자

ACPI는 PC의 전원을 관리하기 위해 만들어진 일종의 규격입니다. 우리가 소프트적으로 전원을 차단하고 절전모드에 들어갔다가 배터리의 양을 체크해서 최대절전모드로 들어가고 하는 등의 모든 전원관련 프로세스는 이 녀석이 담당합니다.

사실 이 ACPI는 하드웨어 업체에서 어느정도 표준에 맞추어서 만들어냅니다. 그러니까 몇번 핀에 어떤 신호를 주면 전원이 차단된다던지 하는 것들 말이지요. 이를 OS가 읽어내서 하드웨어에 그렇게 작동되게끔 하는 것입니다. (말이 조금 어렵지요? 그러니까 OS가 부팅 될 때 메인보드에서 OS에 자신의 사용설명서를 제공한다고 생각해보세요)

그런데 Windows는 워낙 괴랄한 하드웨어 지원을 하기 때문에 ACPI이전의 APM이라 불리는 전원 관리자부터 각 회사마다 제멋대로 만들었던 전원관리방식까지 다 지원합니다. 그래서 몇몇 하드웨어 업체는(특히 중국산 노트북이 대표적) ACPI를 대충 만들어서 넣어도 Windows가 알아서 잘 해주니까 그냥 파는 경우가 있습니다.

이런 하드웨어에 리눅스를 설치하면 OS가 ACPI를 제대로 이해하지 못해서 엉뚱한 전원제어를 할 수도 있습니다. 예를 들면 멀쩡히 작업을 하고 있는데 온도가 조금 높아졌다고 바로 시스템을 종료한다던지 배터리가 50%남았는데 배터리가 없다고 판단해서 꺼버린다던지 하는 것들을 말합니다.

이런 시스템에서 게임을 한다면 어떻게 될까요? 자칫 잘못하면 시스템이 과열되었는데도 팬이 돌지않아서 죽어버릴 수도 있고 데이터오염으로 세이브가 날아갈 수도 있습니다. 제일 큰 문제는 그냥 고장나버리는 것이겠지요.

현재 우리나라에서 팔리는 대부분 컴퓨터는 정상적인 ACPI를 가지고 있다고 생각합니다. 특히 유명업체를 쓴다면 신경 쓸 이유는 더더욱 없겠지요. 하지만 해외에서 직접 구매해서 쓰는 경우도 있을 수 있고 일부 메인보드가 문제가 있을 수도 있습니다. 이런 것이라면 SteamOS를 설치를 한다고 해도 제대로 된 SteamBox로 쓸 수는 없을 것입니다.

===

지금까지 리눅스에서 게임을 하는 것에 대한 하드웨어 이야기를 했는데 사실 이런 저런 이야기를 했지만 사실 하드웨어적으로 큰 문제는 없습니다.

GPU의 경우에는 드라이버 지원이 결국에는 잘 되고 있는 것이고(Nvidia는 바이너리로 AMD는 오픈소스로)

CPU지원은 나온지 얼마 안 된 모델이 아닌 검증된 모델을 사용하면 그만이니까요.

ACPI문제는 이상한 업체의 부품이 아닌 유명업체를 쓰면 되는 것입니다. (보통 게임용 PC를 맞추시는 분들은 좋은 부품을 쓰려고 하니까 큰 문제는 없는 셈이지요.)

하지만 소프트웨어는? 음...

이건 다음에 이야기해보도록 하지요.

일반인들은 잘 모르겠지만 현재 PC들은 32비트 시스템과 64비트 시스템이 섞여 있습니다. 64비트 시스템이라는 것은 기본적인 CPU 연산이 64비트로 구성되어 있다는 것이고 32비트 시스템이라는 것은 CPU가 32비트를 기반으로 연산을 한다는 의미입니다.

이렇게 말하면 잘 모르겠지요.

그래서 요즘은 이렇게 이야기 하지요.

"64비트 시스템이 아니면 램을 4GB이상 못쓴다."

과연 이게 맞는 말일까요? 솔직히 틀린 말은 아닙니다. 데스크탑용 Windows의 경우 32비트 에디션을 쓰면 4GB를 인식 못합니다. 물리적 메모리 주소를 32비트의 경우 그 이상 못 쓰기 때문입니다. 하지만 CPU의 설계자들은 이미 이를 예상하고 32비트에서 4GB이상의 메모리를 쓸 수 있게 설계를 해 놓았습니다.

일명 물리적 주소 확장(Physical Address Extention = PAE)이라고 해서 펜티엄 시리즈부터 이를 추가해 놓았습니다. 그리고 OS에서도 이를 쓸 수 있게 조치가 취해져 있습니다. 다만 OS에서 소프트적으로 제한을 걸었다는 것 뿐이지요.

https://ko.wikipedia.org/wiki/%EB%AC%BC%EB%A6%AC_%EC%A3%BC%EC%86%8C_%ED%99%95%EC%9E%A5

일단 위키피디아를 참고하면 Windows의 서버용 OS(데이터센터 에디션)에서 메모리 제한이 풀려있습니다.

출처인 Microsoft 홈페이지 내용을 보시면 더 정확합니다. https://msdn.microsoft.com/en-us/library/aa366778.aspx

Windows 2003 R2 Enterprise와 Windows 2008 Enterprise, Datacenter에서는 32비트 버전도 4GB이상의 메모리를 쓸 수 있습니다. (각각 16GB와 128GB를 쓸 수 있습니다.) 이렇게 제한을 건 이유는 당연히 가격문제 때문입니다. Enterprise 버전은 다들 알다시피 가격이 어마어마합니다. 그리고 소매점에서 구하는 것이 아닌 하드웨어와 함께 구매하게 되어있지요. 만약 가정용, 소매점 버전에 이 정도 차등의 제한을 걸지 않았다면 우리는 정말 비싼 가격으로 Windows를 쓰고 있을 것입니다.

자 이제 리눅스로 와 볼까요? 리눅스는 애초에 가격적인 문제가 없습니다. 당연히 메모리 문제를 PAE를 활성화 하는 것으로 해결했습니다. Windows는 제한을 걸었지만 리눅스는 그럴 필요가 없기에 PAE를 활성화한 커널을 설치하는 것으로 32비트에서 4GB이상의 메모리를 쓸 수 있습니다. 하지만 이를 이용하는 사람은 많지 않습니다. 왜냐하면 64비트전환이 이미 2008년부터 성공적으로 진행되었기 때문입니다. 그 당시부터 나오던 말이 "64비트 CPU를 쓴다면 그냥 64비트 버전을 쓰는 것이 가장 좋다. 실제로 성능이 1.5배 좋아지기 때문이다." 라는 말이 돌고 있었습니다. 실제로 그러기도 했고 당시 64비트 CPU는 AMD의 Athlon64뿐이었는데 Atholn64는 32비트 호환모드는 소프트에뮬레이션을 했기에 딜레이가 느껴졌습니다.

게다가 64비트 전환을 하려면 CPU만 64비트이기만 해도 안 되고 OS도 64비트를 지원해야 하며 심지어 프로그램도 64비트용으로 컴파일 되어야 합니다. 여기서 리눅스는 오픈소스의 힘을 발휘하여 Athlon64에서 완벽한 성능을 뿜어내게 되었습니다.

리눅스는 64비트커널이 2.6부터 지원되어졌으며 64비트 컴파일러가 이미 2000년 중반에 보편화 되었고 64비트 컴파일러를 통해 만들어진 64비트 프로그램이 2000년대에 당연히 지원되어졌습니다. 이제는 구형 시스템에서 돌아가지 않는 이상 32비트를 굳이 써야하는 경우가 없어졌다고 봐야 할 겁니다.

만약 리눅스가 PC의 대세였다면 이미 2000년대 중반에 64비트 전환이 완벽하게 이루어졌을 것입니다. 실제로 서버의 경우에는 64비트 전환이 그렇게 이미 이루어졌습니다.

하지만 다들 알다시피 PC의 대세는 Windows였고 Windows를 만든 마이크로소프트는 AMD보다는 인텔과 더 친했기에 AMD64용 OS보다는 인텔의 IAT64에 더 관심을 갖고 있었습니다. 하지만 마이크로소프트도 IAT64가 기존의 프로그램을 쓸 수 없다는 큰 단점이 있다는 것을 알고 지원을 적당히 해주다가 빠졌다고 합니다. 그리고 AMD64용 OS를 뒤늦게나마 따로 내놓게 됩니다.(WindowsXP x64 Edition) 그리고 Windows Vista부터 64비트 버전(AMD64용)을 홍보하면서 이를 퍼지길 기다렸는데 Vista는 다들 알다시피 망했지요.

그러니까 당시 CPU의 대세는 사실 인텔이 아닌 AMD였고 AMD의 CPU는 64비트OS가 아니면 성능이 떨어지는 문제가 있었습니다. 이는 AMD의 문제가 아닌 32비트OS를 쓰는 것이 문제였다고 봐야 합니다. 인텔도 AMD64호환 CPU를 내놓지만 역시 AMD의 기술을 이용했기에 같은 문제가 있었습니다. (물론 인텔에서는 AMD64라고 하지 않고 x64라고 부르기는 합니다. 하지만 AMD에서 크로스 라이센스로 받아온 기술입니다.) 어쨌건 메모리의 크기를 제한하는 것을 홍보한 덕에 64비트 OS가 어느정도 빠르게 확산되었고 요즘 PC에 32비트 버전을 깔면 멍청하다는 소리를 듣게 되었습니다.

어쨌건 이렇게까지 하면서 64비트 전환이 이뤄졌을까요?

제 생각이지만 아직까지도 32비트 프로그램이 굴러다니는 이상 전환은 요원하다고 보고 있습니다. 멀리 갈 것도 없이 PC게임들은 아직도 32비트로 구동되는 경우가 많고 4GB이상의 메모리를 요구하지만 정작 바이너리는 32비트인 경우가 대부분입니다. 64비트 CPU에서 32비트 구동은 조금 느리게 구르게 되어있습니다. 요즘 CPU가 워낙 빨라서 성능 차이는 많이 줄었지만 그래도 묘하게 성능이 아쉬운 것이 많습니다.

결론은

아직도 Windows에서는 64비트 전환이 이루어지지 않았다.

리눅스에서는 64비트 전환이 거의 완벽히 이루어졌다.

정도로 할 수 있겠습니다.

다만 전문 프로그램의 경우 64비트버전만 제공하는 경우가 늘고 있는 것으로 보아 Windows의 64비트 전환도 10년 내에는 완벽히 이루어지지 않을까라는 생각이 드네요. (리눅스는 10년도 전에 전환이 거의 다 되었는데!)

솔직히 그럴 거라고 예상은 했는데 하모니카 이미지가 이제 다운로드 링크에서 내려갔습니다.

솔직히 17.3에서 멈춰 있는 것도 불안했는데 (그래서 자체적으로 18.2버전을 배포했지요.) iso링크가 죽어버렸습니다.

한국에 리눅스에 대한 이미지를 한층 끌어올렸다는 평가를 받는 하모니카가 이렇게 망가지는 것인가요?

솔직히 말해서 기분이 매우 나쁩니다. 정부 지원이 끊기자마자 바로 이렇게 된다는 것도 짜증나고 OS라는 것은 지원이 끊기면 그대로 끝인데 관리까지 손을 놓고 있는 것을 보면 화가 나는군요.

사실 2.2버전도 2016년 안에 나온다고 해놓고 지금 2017년입니다. 그것도 8월이지요.

아무리 리눅스민트의 한국어화라고 폄하 받기는 했어도 사람들이 괜히 하모니카를 찾은 것이 아닌데...

지금 하모니카가 쓰이고 있는 시스템은 어쩌려고 이러는 건지 모르겠습니다. 중국의 기린은 새로운 데스크탑 환경도 만들어서 잘 써먹고 있는데 한국에서 써먹고 있는 OS가 이러면 더 이상 사람들이 정부주도 운영체제라는 것을 믿지 않을 겁니다.

정부에서 한 것치곤 잘 했다는 소리를 듣던 하모니카인데 이렇게 사라지는건가요?

VAAPI : https://en.wikipedia.org/wiki/Video_Acceleration_API

VDPAU : https://en.wikipedia.org/wiki/VDPAU

XvBA : https://en.wikipedia.org/wiki/X-Video_Bitstream_Acceleration

리눅스에서 동영상 가속을 위한 방법은 3가지가 있습니다.

우선 인텔이 만든 Video Acceleration API 줄여서 VAAPI라 부르는 API가 있습니다. libva.so를 이용하고 인텔이 만들었기에 당연히 인텔GPU에서 지원을 합니다. 그리고 AMD의 경우에는 오픈소스 드라이버를 이용할 경우 지원을 합니다. (Padoka PPA를 이용하시면 VAAPI가 AMD에 한해 비활성화 됩니다. 이유는 아래를 보시면 압니다.)

그리고 Nvidia가 만든 VDPAU가 있습니다. 지금이야 개나소나 다 지원하고 거의 업계표준이 되어버린 H.264 포맷이 처음 등장하고 나서 세상에 충격을 줬던 바로 그 시절에 태어난 물건입니다. 당시 PC성능으로 H264의 FHD영상은 재생이 버거워서 이런저런 방법을 강구해야 했습니다. 그 때 Nvidia가 PureVideo라는 것을 내놓았고 ATi(현재 AMD로 흡수)에서도 무언가 내놓기는 했는데... 아무튼 이 당시부터 GPU를 이용한 디코딩이 활성화 되었습니다. 그 때 만들었던 PureVideo를 리눅스로 이식하면서 VDPAU라는 이름으로 가져온 것입니다. 대략 2000년대 중후반 쯤이겠군요. 생각보다 역사가 좀 된 물건입니다.

지금은 AMD의 오픈소스 드라이버와 Nvidia의 드라이버를 사용하면 활성화가 됩니다. 인텔은 별도의 Wrapper를 사용하면 지원이 됩니다.

마지막으로 나온 XvBA란 물건이 있는데 이놈은 Catalyst를 설치했을 경우 XvBA를 지원하는 프로그램에서 활성화가 됩니다. 위의 위키피디아를 보시면 아시겠지만 다른 API에 비해 문서가 부실한데 이유야 당연히 악명높은 Catalyst를 사용했을 때만 활성화 되는데다가 위의 설명을 보셨을 아시겠지만 AMD의 오픈소스 드라이버가 VAAPI와 VDPAU를 둘다 지원하는 반면 XvBA에 대해서는 일언 반구도 없습니다. 즉, 버려진 자식 취급인것이지요.

그러니까 우분투 16.04이후로 Catalyst도 망했고 (어차피 AMDGPU드라이버로 바뀌었으니) 기존 사용자도 Catalyst를 설치할리 없으니 XvBA는 무시하도록 합시다.

VAAPI와 VDPAU는 다른 두 업체에서 처음 시작했지만 지금은 Freedesktop.org에서 관리하고 개발하고 있습니다. 물론 인텔은 VAAPI를 지원하고 있고 Nvidia는 VDAPU를 밀고 있지만 이 둘중에서 어떤 것이 승리할지는 아무도 모릅니다.

그리고 이 둘이 함께 개발이 되면서 서로가 서로를 대신하는 Wrapper도 함께 개발되었습니다. 우분투라면 vdpau-va-driver라는 패키지와 libvdpau-va-gl이란 두 패키지를 보셨을 겁니다.

패키지 설명을 잠깐 볼까요?

그러니까 말이 어려워서 그런데 쉽게 말하자면 VDPAU 칩셋에서 VAAPI프로그램을 돌리기 위한 패키지 (vdpau-va-driver)와 VAAPI칩셋에서 VDPAU프로그램(Adove Flash 같은)을 돌리기 위한 패키지(libvdpau-va-gl)인 것입니다.

솔직히 어떤 프로그램이 VAAPI를 지원하고 VDPAU를 지원하는지는 굳이 알 필요가 없는 것이 우분투는 알아서 이를 적용하기 때문입니다. 그러니까 끙끙 싸매지 마시고 그냥 그렇다고 하시면 됩니다.

VLC나 MPlayer를 사용하실 때 출력 드라이버가 어쩌고 하는 것을 보실수 있는데 그냥 자신의 그래픽칩셋에 맞춰서 선택하시면 됩니다.

참고 VDPAU https://www.freedesktop.org/wiki/Software/VDPAU/

VAAPI https://www.freedesktop.org/wiki/Software/vaapi/

나만의 우분투를 만드는 Customizer. 이 프로그램으로 작업을 한다는 것은 꽤 삽질을 요합니다. 하지만 Customizer로 하는 작업이 어떤 커스터마이징을 하더라도 그 순서는 거기서 거기입니다.

1. Customizer로 ISO파일을 열고

2. 패키지를 받아오는 서버를 바꾼다음

3. Customizer의 터미널을 열고 명령어를 이용해서 이런저런 설정을 합니다.

4. 다시 ISO로 묶은 다음 가상머신에서 테스트.

5. 마음에 안 들면 다시 3번으로

여기서 다른 것은 중간에 터미널을 이용해서 어떤 패키지를 설치하고 어떤 패키지를 뺄 것인지 정도입니다. 나머지는 다 똑같지요.

제가 만들었던 것을 몇가지 나열하자면

- 제 누님을 위해 만든 한글2008+리브레오피스+Chromium Browser+한글입력기만을 넣은 LXDE기반 배포판(총 용량 240MB)

- 우분투 기린 한국어판

- 졸업작품 구동용 Openbox기반 USB전용 라이브버전

- 졸업논문용 실험을 위해 만든 시리얼통신+MATLAB구동 전용 라이브 USB버전

등이 있습니다.

이중에서 제가 제일 걸작으로 보는 것은 제일 첫번째로 있는 한글2008을 넣어서 만든 버전입니다. 누님이 쓰는 고물 노트북에서도 원활하게 구동될 수 있도록 심혈을 기울여(?)만든 커스텀버전입니다. 당연히 따로 배포할 생각도 없고 배포 할 수도 없습니다.(한글2008 때문에) 하지만 이것도 결국 apt-get이나 dpkg로 패키지를 설치하고 지운 것은 동일합니다. 결국 딱히 무언가 특별한 방법을 쓴 것은 아니란 뜻이지요.

SUSE Studio의 모습 자신이 선택한 프로그램과 저장소 위치등을 지정할 수 있게 만들어져 있다. 출처 : https://en.wikipedia.org/wiki/SUSE_Studio#/media/File:SUSE_Studio.png

Debian, Redhat, Slackware와 함께 리눅스 배보판계의 살아있는 조상님인 SUSE에서는 SUSE Studio란 서비스를 하고 있습니다.

https://susestudio.com/

이것이 어떤 서비스냐면 SUSE리눅스를 기반으로 자신이 원하는 소프트웨어를 웹상에서 추가하고 빼는 것으로 자신만의 SUSE기반 배포판을 만드는 서비스입니다. 즉, 웹으로 하는 커스터마이징이라고 볼 수 있습니다.

이는 굉장히 혁신적이고 재미있는 서비스라고 할 수 있습니다. 사람에 따라서는 무조건 설치하는 프로그램도 있지만 필요없는 프로그램도 많습니다. 특히 우분투는 미리 설치해주는 프로그램이 많기 때문에 취향에 맞춰 이후 손을 대는 사람도 많습니다.

하지만 이런 서비스를 이용한다면? 배포판을 다운로드 받기전에 해당 프로그램을 미리 추가할 수도 있고 필요없는 프로그램을 뺄 수도 있는 것입니다. 단점은 저장소에 없는 프로그램은 미리 넣을 수가 없다는 것입니다. 하지만 PPA가 활발하게 만들어져 있는 우분투 특성상 저장소 걱정은 거의 없다고 볼 수 있겠지요.

실제로 저는 우분투 설치후 바로 하는 작업이 한글설정+한글입력기 설치입니다. 기본으로 주는 ibus가 저는 마음에 들지 않거든요. fcitx나 Nimf, Uim같이 훌륭한 입력기가 있기 때문에 ibus를 지우고 바로 해당 입력기를 설치합니다. 그런데 SUSE Studio같은 서비스가 있다면 배포판을 다운로드 받기전에 미리 웹상에서 작업을 할 수 있겠지요. 게다가 2017년 현재에는 설치에 필요한 USB메모리의 용량이 넉넉하기 때문에 GIMP같이 거대한 프로그램도 미리 넣어서 설치와 동시에 사용할 수도 있을 것이고요.

이외에도 Lubuntu나 Xubuntu같은 배포판말고도 Openbox+tint2+conky등으로 가볍게 배포판을 꾸리고 싶으신 분들도 있을 겁니다. 그런 분들도 웹에서 패키지를 설정하는 것으로 만들 수 있을 것입니다.

하지만 아직 우분투는 그런 서비스를 하고 있지 않습니다. 우분투는 이런 방법대신 여러개의 배포판을 만드는 것으로 대신했지요. Lubuntu, Xubuntu, Kubuntu 등.

우분투방법도 선택권을 넓히는 것으로 나쁜 것은 아니었지만 약간 아쉽다는 생각이 듭니다. ubuntu studio란 이름을 쓴 무언가가 했지만 그것은 이런 것이 아니었습니다.

그런데 결국 apt-get 이라는 것은 서버상에서 Customizer를 이용해서 ISO를 만들고 해당 ISO를 최종 사용자에게 전송하는 것은 그렇게 어렵지는 않겠다는 생각도 듭니다. python-CGI나 서버어플리케이션에서 자주 사용하는 방법이니까요. 하지만 문제는누가 이런 귀찮은 서비스를 하겠냐는 것과 캐노니컬조차 관심이 없다는 것이 가장 큰 문제가 아닐까 생각합니다.

이런 것, 저만 희망하는 걸까요?