Minitab은 통계용 프로그램입니다. 다른 용도로도 많이 쓰이곤 하지만 SSPS나 기타 통계용 프로그램보다 싼 것이 장점이지요. 하지만 Windows만 지원하기 때문에 통계 분석을 위해서는 Windows를 필요로 합니다.


우분투에서도 이런 프로그램이 없지는 않지만 R같은 놈 처럼 프로그래밍을 필요로 하거나 Python의 모듈처럼 초보자가 쓰기에는 힘든 구성을 지니곤 합니다. 그리고 무엇보다 교육자료들이 하나같이 Minitab기준이라 R이나 Python이 분석용으로 쓰이기 참 어렵기도 합니다.


그러면 방법은 하나지요...Wine으로 설치하는 수밖에 없습니다.


그래서 Minitab의 구버전인 15버전을 평가판으로 설치했습니다. Playonlinux에서 설치를 누르고 non-listed program을 선택하신 다음 wine버전을 1.7.5이상으로 선택하시고 설치하시면 됩니다.


minitab 15버전 평가판은 다음 링크에서 다운로드 받으시길 바랍니다.

https://drive.google.com/open?id=0B5LQBL0rAm2fNV9Ld29IVzZjMVk&authuser=0


그리고 추가 라이브러리로 wsh56과 wsh57을 설치해주셔야 그래프가 무사히 뜨게 됩니다. 이거 없으면 그래프가 안 뜹니다.


아 그리고 실험계획법(Design Of Experiment)의 부분 계획을 위해서는 usp10.dll파일이 필요합니다. 아직 따로 Playonlinux에서 지원을 하는 듯 하지는 않더군요. 그래서

usp10.dll.zip

이 파일안에 있는 usp10.dll파일을

~/PlayOnLinux's virtual drives/(Minitab Prefix이름)/drive_c/windows/system32 압축을 풀어서 넣어주신뒤 wine 설정(구성 버튼을 누르고 Minitab의 Prefix를 선택해 주시면 Wine탭에 Wine 설정버튼이 있습니다.)에서




usp10을 추가해주시면 됩니다.


그리고 Mtb.exe파일을 바로가기로 추가해주시면 됩니다.



이제 리눅스에서 Minitab이 실행 되었군요.

.....

이렇게 쉬운 것을 설명하려고 이 글을 올린 것은 아닙니다....




이렇게 wine으로 Minitab을 실행하면 한 가지 어마어마한 일이 일어나게 됩니다.


바로....


...

남은 기간이 30일에서 변하지를 않습니다. 저는 Minitab을 설치한지 약 7일 정도가 지났음에도 어찌된 영문인지 며칠이 지나도 30일이 남았다고 나옵니다.


..디버그항목을 보니 서비스의 일부가 실행이 안 되면서 작동이 안 된듯한데 그 부분이 어이없게도 날짜 제한 부분이었나 봅니다.


wine이라는 특이한 환경을 쓰다보니 별 희한한 일도 다 생기네요 참.

,

 여러분들은 그림판을 어떻게 생각하시나요? 어떤 분들은 그냥 말 그대로 그림 그리는 판정도(?)로 생각하시는 분도 계시고, 예술 작품용(?) 캔버스로 활용하시는 분들도 많으실겁니다. 사실 이만한 성능에 이 정도 메모리만 쓰는 프로그램도 사실 드뭅니다. 까놓고 말해서 쓸모없기로 유명한 Windows 기본프로그램 중 몇 안되는 제 값 하는 프로그램이 메모장과 그림판이라고 할 정도이니 말 다했습니다.  



출처 : 마이크로소프트 요새 그림판은 XP이전의 그림판과 궤를 달리한다. 역시 Windows 가격 20만원 중 5만원 이상의 값 어치 하는 프로그램.

 말 그대로 그림을 그리는 판이지만 그동안 우분투에 그림판같은 프로그램은 없었습니다. 그렇다고 우분투에서 그림판 쓰자고 Wine에 그림판 깔기도 참 뭐합니다. 그동안 우분투에서 기본 그래픽 에디터라고 하면 당연하다면 당연하게 Gimp였습니다. 그런데 Gimp란 이 놈은 사실 그림판에 대응하기 보다는 포토샵에 필적하는 녀석이다보니 간단한 사진에 글씨 넣기라던가 강조 표시정도에 써먹기에는 너무 쓸데없이 무거운 편입니다. (물론 일반인은 전체 기능의 5%밖에 못 쓴다는 포토샵보다는 훨씬 가볍습니다.)

저도 가끔 블로그에 그림을 올릴 때 살짝 편집을 하기는 하는데 그때마다 Gimp를 쓰기에는 너무 Gimp가 쓰기 힘들더군요. 못 할 것은 없는데 소잡는 칼로 닭 잡는듯한 느낌입니다. 간단한 레포트에 넣을 그래프에도 그림판정도면 딱인데 Gimp는 작업하기 참 무거웠습니다.


아무리봐도 Gimp는 간단한 편집에는 부적합하다. 그래프에 글씨 넣는 수준에 이걸 쓰는 것은 철조망 세우는데 타워크레인 쓰는 느낌.

정확히 말하자면 못할 것은 없습니다. 하지만 가볍게 할 작업을 굳이 무겁게 한다는 것이 아쉬웠습니다. 더욱이 Gimp는 용량 문제로 우분투 기본 탑재 프로그램에서 퇴출 당하기까지 했습니다. 


하지만 역시 수요가 있으면 공급도 있는 법. 우분투에 그림판 같은 존재가 드디어 등장했습니다. 이름하여 mtPaint Graphic Editor입니다.


mtPaint의 모습. 누가 봐도 그냥 그림판 클론이다.

 위의 스크린샷을 보시면 알겠지만 보면 그냥 그림판하고 크게 차이가 나지 않는 것을 보실 수 있습니다. 어쩌면 그림판의 Windows7 이후 버전보다는 XP 이전의 클래식한 모습에 가깝습니다. 즉, 그동안 우분투 사용자들은 Gimp가 맡았던 고급 기능의 그래픽 에디터와 함께 클래식 그림판이 맡았던 역할인 간단하게 그릴 수 있는 캔버스, 이것이 필요했던 것이지요.


 이 놈을 쓰다 보니 그동안 소 잡던 칼인 Gimp가 실행되는 횟수가 확 줄었습니다. 즉, 전 그동안 간단한 편집만 했기에 Gimp같은 무거운 프로그램이 필요 없었는데 대신할 것이 없었던 것이지요.


 굉장히 가볍고 좋군요. 왜 그동안 이런 프로그램이 없었는지 안타깝기만 합니다. 아니면 내가 못 찾았던 것일지도 모르겠지만요.

,

이 이야기는 VMware를 유용하게 쓰시고 계실 모든 분들에게 통용될 이야기입니다. 우분투에서만 이용되는 이야기는 아닙니다. CPU성능이 더럽게 좋아서 소프트웨어 렌더링이 훨씬 더 퍼포먼스가 좋다던지(Intel, S3) 공식드라이버가 워낙 거지같아서 오픈소스프로젝트의 드라이버를 사용하시는(AMD) 모든 분들에게 다 먹히는 이야기이니 유용하게 쓰시기 바랍니다. Windows에서는 후자의 경우가 없으므로 별로 쓸 일은 없겠지만 간혹 베타드라이버에서 VMware가 가속이 안된다고 한 경우가 있으니 Windows 사용자분들도 써먹을 수 있습니다.


VMware를 쓸 때 3D 가속을 하는 이유는 무엇일까요? 보통 VirtualBox에서는 일단 Direct Rendering이 가능하다는 가정하에 3D 가속 설정만 하면 그냥 가속 모드로 들어가는 것과는 다르게 VMware는 오픈소스 드라이버이거나 최신의 드라이버의 경우 3D 가속이 검증이 안 되서 그런 것인지 3D가속을 꺼버립니다.



호스트에서 3D 가속이 안 된다고? 리눅스에서 AMD쓴다고 무시하냐?


VMware가 아무래도 기업용으로 자주 쓰이다 보니 업데이트가 늦는 편이고, 안정성을 추구하다보니 드라이버에 대해서도 상당히 보수적인 입장을 취합니다. 하지만, VMware가 아무리 보수적이라고 해도 방법이 없지는 않습니다. 환경설정에는 안 나와있지만 수동으로 설정을 하면 어떤 드라이버를 쓴다고 해도 3D 가속을 쓸 수 있습니다.


VMware의 가상머신이 있는 곳(~/vmware)에서 vmx파일을 텍스트 에디터로 열면 여러분들이 설정한 설정 값들이 텍스트형태로 나와 있음을 알 수 있습니다. 그 중 제일 마지막에 다음과 같은 한줄만 추가하면 됩니다.



mks.gl.allowBlacklistedDrivers = "TRUE"


이 한줄만 추가해주시면 이제 오픈소스드라이버를 쓰든, 베타드라이버를 쓰든 아니면 소프트렌더링을 쓰든(...) 3D 가속을 가상머신에서 하는 것을 보실 수 있습니다.

,

 이제는 Wine의 성능이 상당히 좋아졌습니다. 예전의 고작(?)윈도용 프로그램 몇개 돌리던 호환 레이어였던 Wine은 이제 상당한수준의 산업용 프로그램도 무리없이 굴릴 수 있게되었습니다. 물론, 이 모든 것이 다 사용자달의 피드백과 개발자분들의 열의 덕입니다. 


 이번에는 산업용으로 많이 쓰이는 시리얼 통신을 wine구동 프로그램으로 굴리는 방법을 알려드리고자 합니다. 그러기 전에 시리얼통신을 왜 쓰는 것인지에 대해 말씀 드려야겠네요.


 주로 시리얼 통신은 작게보면 이제는 가정에서 볼 수 없는 RS-232 9핀 커넥터를 주로 이용해서 주변 장비를 구동하는 통신 방법입니다. 본래 시리얼 통신은 직렬구조의 통신 방법을 모두 통틀어서 하는 말입니다. (Serial의 의미가 직렬이란 의미입니다.) 그리고 이 RS-232방식의 통신은 마우스나 키보드, 그 외의 작은 주변장치의 구동에 많이 쓰""습니다. 하지만 이 시리얼 포트는 프린터포트(혹은 병렬포트,패러럴포트)와 함께 우리가 너무나도 잘 알고 있는 USB에 의해 밀려서 사라졌습니다.


안녕? 내 이름은 시리얼 포트라고 한다. 이제 가정에서 보기 어려워진지 오래지. 하지만 산업현장에서는 내가 엄청 중요하단다.


이 통신방법은 아직도 산업현장에서는 많이 쓰이고 있어서 이를 쓰기위해 USB-RS232변환 젠더 물건도 나와있고 이 시리얼통신은 AVR이나 PIC같은 MCU에도 많이 쓰이는데, 이것을 시리얼통신포트를 쓰지 않고 곧바로 USB에 접속할 수 있게 만든 칩도 나와있습니다.(대표적인 칩이 FTDI사의 칩입니다.) 그러나 산업현장에서는 장비 가격이 가격이다보니 여전히 위에 보이는 포트를 사용하는 장비를 많이 이용하고 있습니다. 이를 최근에 나오는 PC에 쓰기위해서는 USB를 써야만 하는데 USB-RS232변환젠더 같은 물건이 이때 상당히 애용됩니다. 그리고, 이 통신방법은 제가 여러차례 말씀 드렸던 Arduino도 쓰고 있습니다. 단, 이경우는 FTDI칩을 이용한 가상 시리얼통신입니다. 그래서 실질적으로 USB포트밖에 없습니다.


아무튼 시리얼 통신 포트는 점점 사라지고 있지만, 그 통신 방법은 여전히 많이 쓰인다는 것을 아실 수 있을 것입니다. 심지어 Arduinio도 시리얼통신포트는 쓰지 않지만 그 방식의 통신을 하고 있습니다. 그런데 문제는 이 포트를 이용하는 방법이 Windows와 Unix/Linux계열이 다르다는 것입니다.


 시리얼 통신은 어떤 포트인지 구분하는 것인지가 상당히 중요합니다. TCP/IP기반 통신과는 다르게 장비가 연결되었는가에 대한 규격 자체가 없습니다. 그냥 송신명령 내리면 (그곳에 수신을 받을 장치가 있는지 없는지는 무시하고)그냥 해당 포트로 열심히 신호를 보냅니다. 물론 받는 곳도 그냥 들어오면 땡입니다. 그래서 장비 개발자들은 장비와 연결되었는지 확인하는 것을 소프트웨어 적으로 구현해서 집어넣는데 이 때 포트 번호를 제대로 지정하지 않으면 에러메시지가 뜨도록 해놓는 경우가 흔합니다. 그래서 시리얼통신 PC프로그램은 포트설정 하는 것을 굉장히 중요시 여깁니다. 그 다음으로 중요시 여기는 것은 통신 속도(Baud Rate)지만 그것에 대한 이야기는 넘어가겠습니다. 헌데 이 통신포트구분법은 OS마다 다르기 때문에 참 난감합니다. 심지어 규칙조차도 OS마다 천차만별입니다. 


 Windows에서는 시리얼 통신용 포트를 구별할 때 COM1 COM2 ...이런 식으로 COM뒤에 숫자를 붙이는 것으로 구별합니다. 이는 USB-RS232장비나 Arduinio같은 가상시리얼포트도 마찬가지인데 특이한 것으로 연결한 순서대로 붙이되 가상시리얼 장치는 마음대로 COM포트 번호가 바뀌는 것이 일상입니다. 그래서 PC에 가상시리얼 장치(USB-시리얼)를 붙이면 그 다음에 꼭 장치관리자에서 포트번호를 꼭 확인해야 합니다. 그리고 메인보드에 시리얼포트가 있다면 이 포트가 제일 앞 번호를 선점하게 되어 있습니다. 이 경우에는 장치관리자 따위는 무시해도 상관 없습니다. 만약 보드에 시리얼 포트가 2개 붙어있다면 이 둘이 순서대로 COM1 COM2를 먹고 이후에 USB시리얼 장치가 붙으면 순서대로 붙되 쓰다보면(...)한없이 숫자가 엉키는 것을 보실 수 있습니다. (난데없는 이전장치는 COM3이었는데 COM8이라던가...)


 Unix/Linux는 시리얼장치도 하나의 콘솔로 취급합니다. 아니, 사실 여러분이 터미널 창을 하나 띄우는 것을 이 시스템은 가상시리얼 장치 하나가 연결 된 것으로 취급합니다. 사실 시리얼 통신에 제일 가까운 운영체제가 Unix계열입니다. 그러다보니 단순히 COMX로만 구분하는 Windows와 달리 구분하는 것이 상당히 다양합니다. 일단 Unix계열은 해당 어떤 포트가 어떤 포트인지 구별합니다(!). 만약 보드에 달린 시리얼 포트이면 /dev/ttyS0 ~ /dev/ttySX 이런 식으로 구분합니다.(그런데 실제 포트수와 관계없이 여러개가 준비되어 있습니다.) 그리고 USB장치를 이용했으면 /dev/ttyUSB0~ /dev/USBX 로 포트를 구분합니다. /dev/~~라고 적은 것을 보시면 아시겠지만 모든 하드웨어 장치도 파일로 취급하는 Unix계열 특성상 시리얼 포트도 파일로 취급합니다. 이 파일에 무언가를 적거나 읽어내는 것이 시리얼 통신입니다. /dev/ttyX도 있는데 이것들이 바로 여러분 PC에서 터미널로 작업할 때 쓰이는 콘솔입니다. 여기에는 실제 장치가 붙을 일은 절대 없으니까 무시하셔도 됩니다.


서론이 길었습니다. 이제 Wine프로그램을 이용한 장치를 어떻게 시리얼통신에 써먹는지에 대해 말씀 드리겠습니다. ~/.wine/dosdevice에 들어가보시면 C:라고 이름붙여진 링크와 Z:라고 이름붙여진 링크들이 보입니다. 여기에 com1 혹은 com2라고 만들어진 링크를 만들면 wine은 이들을 알아서 시리얼 포트로 인식해줍니다. 참으로 똑똑하지요? 하지만 이를 이용하려면 우선 wine을 이용하되 여러분이 사용하는 프로그램을 어떻게 실행할 것인지에 대해 알고 계셔야 합니다. PlayonLinux를 이용하셨다면 ~/.wine/dosdevice에 링크를 만드시면 안 됩니다. Playonlinux는 그 특징상 가상드라이브를 따로 만들기 때문에 해당 가상드라이브에 들어가셔야 합니다.



com1이란 링크가 보이는지? 이 com1은 /dev/ttyUSB0의 링크이다. 지금은 장치가 연결되어있지 않아서 오류마크가 뜬 것.



즉, Playonlinux를 이용해서 시리얼통신을 하신다면,

~/PlayOnLinux's virtual drives/가상드라이브명/dosdevice


여기에 링크를 만들어야 하고,


그냥 해당 프로그램을 바로 파일매니저 등에서 wine Loader으로 실행하신다면,


~/.wine/dosdevice 

에 링크를 만드셔야 합니다.


무슨 링크를 만들어야 하는데? 라고생각하시는 분들은 아까 제가 모든 하드웨어 장치를 파일로 생각한다고 했던거 기억하시나요? /dev/ttySX 나 /dev/ttyUSBX 같은 파일이 곧 시리얼포트를 의미합니다. 즉 저 파일을 링크(Windows 표현대로라면 바로가기)를 만들어주시면 됩니다. 


링크를 만드는 명령어는 다음과 같습니다.


ln -s 포트이름 wine가상드라이브/dosdevice 


USB형태의 가상포트이며 포트이름이 /dev/ttyUSB0라 했을 때, Playonlinux를 사용하지 않는 다면,


 ln -s /dev/ttyUSB0 ~/.wine/dosdevice/com1


어떤 포트가 실제 장비가 쓰는 포트인지 모르시겠다면, 보드에 달린 포트는 해당 보드의 매뉴얼을 읽으시면 1번포트 2번포트등으로 구분되어져 있다는 것을 아실 수 있습니다. 1번포트가 /dev/ttyS0입니다. 이것은 Windows와 거의 동일합니다. USB를 이용하셨다면 USB시리얼장치를 연결하기 전에 


ls /dev/ttyUSB* 

를 보고, 장치 연결 후에 같은 명령을 쳤을 때 추가된 포트가 바로 해당 장치가 쓰는 포트입니다. 이는 무식하지만 확실한 방법입니다.(저도 상당히 애용합니다.) 정 모르시겠다면 그냥 USB시리얼 장치를 순서대로 꽂으면 /dev/ttyUSB0, /dev/ttyUSB1 이런 식으로 올라갑니다. Windows 마냥 COM3 그다음 장치가 COM8이 되는 이상한 현상은 거의 없다고 보시면 됩니다.


어쨌거나 위의 예시에서는 com1이라는 이름으로 링크를 걸었는데 보시면 아시겠지만 Wine내에서 해당 시리얼 포트를 COM1로 취급한다는 의미입니다. 즉, 이제 Wine 구동 프로그램에서 COM1로 접속을 하시면 별 문제없이 접속이 되는 것을 확인하실 수 있습니다.


,

민트에서 루분투로 갈아탄지 2일째입니다. 루분투는 성능상의 잇점때문인지 Pulse-audio를 사용하지 않고 Only Alsa정책을 펴고 있었습니다. 그런데 제 노트북에서는 소리가 안 나오는 기현상이 일어나서 Pulse-audio를 설치 했습니다.



sudo apt-get install pavucontrol

이걸로 음량 조절 기능을 설치하고 음량을 조절 할 수 있게 됩니다. 터미널에서 pavucontorl만 치면 실행됩니다. 저는 소리가 안 나오는 원인이 HDMI를 기본 하드웨어로 잡아서 그렇더군요. HDMI 관련 장치를 Off로 설정하니 이후부터는 별 문제 없이 스피커로 출력이 잘 되었습니다.


HDMI어쩌고 장치를 off로 설정하면 스피커로 소리를 들을 수 있다. HDMI를 사용한다면 HDMI를 On하고 쓰면 된다.

그런데 문제가 하나 생기더군요. 키보드에 있는 볼륨 조절키를 아무리 눌러도 조절이 제대로 되지를 않았습니다. 원인은 Openbox 단축키 설정이 Alsa로 되어있어서 그런 것이었습니다.

그럼 그 설정을 Pulse-audio용으로 바꾸면 그만입니다.

단축키를 바꾸는 방법은 두가지가 있습니다. 직접 ~/.config/openbox/lubuntu-rc.xml를 수정하는 방법과 obkey라는 유틸리티를 쓰는 것입니다. 이번에 저는 obkey를 써보겠습니다.


https://code.google.com/p/obkey/downloads/list


위의 링크로 들어가서 obkey를 다운로드 받습니다. 그 다음 원하는 곳에 압축을 풀고 터미널을 열어줍니다. 터미널에서 찾아가기 쉽게 ~/obkey/ 정도에 압축을 풀어놓는 것이 좋겠지요?


이제 obkey를 압축 푼곳으로 찾아갑시다. ~/obkey에 압축을 풀었다면 cd ~/obkey/ 찾아갈 수 있습니다. 그 다음에 다음과 같은 명령어를 줍시다.


./obkey ~/.config/openbox/lubuntu-rc.xml


그러면 다음과 같은 설정 창을 볼 수 있습니다. 여기서 우리가 원하는 것은 XF86Audio 입니다.


모든 설정이 끝나고 저 버튼을 누르지 않으면 말짱 꽝이다. 그리고 설정 꼬일 것을 대비해서 ~/.config/openbox/lubuntu-rc.xml 파일을 백업해두자

쭉 찾아보면 Key열에 다음과 같은 세 개의 문장이 보입니다.


XF86AudioRaiseVolume

XF86AudioLowerVolume

XF86AudioMute


이 세 개를 Pulse-audio에 맞게 설정 하는 것이 이번 글의 목표입니다.


일단 찍어보시면 오른쪽 위에 Command라고 써있는 칸이 보입니다. 그곳에 보면

amixer ~~~이렇게 쓰여 있는데 이건 Alsa용 명령어 입니다. Pulse-Audio용으로 쓰려면 이걸 고치면 됩니다.



command 칸을 보면 이미 pactl~~로 고쳐놓았다. 이것이 Pulse-audio용 볼륨조절 명령이다. 터미널에서도 먹히니 한번 심심하면 해보자


고쳐야 하는 것은 다음과 같이 고치시면 됩니다.

 Key이름

 ALSA 명령

 Pulse-audio 명령

 XF86AudioRaiseVolume

 amixer -q sset Master 3%+ unmute

 pactl set-sink-volume 0 +3%

 XF86AudioLowerVolume

 amixer -q sset Master 3%- unmute

 pactl -- set-sink-volume 0 -3%

 XF86AudioMute

 amixer -q sset Master toggle

 pactl set-sink-mute 0 toggle


이제 xml파일을 저장하고 로그아웃 했다가 다시 돌아오면 단축키로 볼륨 조절 되는 것을 보실 수 있습니다. 참고로 저 3%는 고칠 수 있습니다.


이외에도 obkey로 단축키를 마음대로 설정 가능하니 마음껏 이용해보시길 바랍니다.

터미널이나 파일매니저, 웹브라우저는 단축키로 해 놓으면 아주 편합니다.

,

이전에 제가 쓴 글을 보면 AMD를 신명나게 욕을하면서 드라이버 지원이 참 안 좋다는 이야기를 한 적이 있습니다. 그리고 오늘도 역시 AMD는 리눅스 사용자에게 정말 거지같다는 것을 보여주었습니다.


이미 Wine 관련으로 한바탕 개고생을 선보여주셨던 Catalyst님이 이번에는 32bit OpenGL라이브러리 관련으로 엿을 먹여주었습니다. 사실 이번에 메모리 관련 이슈로인해 루분투로 갈아탔는데 민트에선 그럭저럭 별 문제 없던 Playonlinux에서 다음과 같은 오류를 뿜어주시더군요.


32비트 라이브러리가 없으니 설치하라는 거다. 근데 catalyst깔면서 이미 다 깔린 상태였다

32비트 라이브러리가 없으니 해결하라는 의미인데 혹시나 하고 Win32프로그램을 돌려보니 오류가 와장창....wine과 fglrx관련 이슈가 있기는 있더군요. 그런데 64비트우분투에서 win64비트프로그램을 돌리는 것은 별 문제가 없는데 32비트는 이러한 문제가 생겼습니다. 그리고 32비트 리눅스용 프로그램도 OpenGL사용하는 프로그램에 한해 같은 증상이 있었습니다. 사실 윈도용 프로그램 아니면 32비트 프로그램 쓸 일이 없기는 한데(한글2008 제외) 그래도 이건 좀 아니지 않나 싶습니다.


그래서 오늘 하루를 다 허송세월한 뒤에 오픈소스 드라이버가 없나 찾아보니 이미 개발이 되어져 있더군요. 다만 커널 3.15이상이어야 하고 Xorg도 PPA를 통해 업그레이드를 해야 합니다. 그런데 이미 Catalyst에 화가 머리끝까지 난김에 그냥 커널 업데이트 및 Xorg 업데이트를 했습니다.


그랬더니....


화면이 훨씬 더 부드러워지고 Firefox에서도 GPU가속이 됩니다!(그동안 GPU가속은 남의나라 이야기였습니다.) 이게 뭐지? 싶어서 glxgears를 돌려봤더니 60fps으로 제한을 걸어져 있더군요. Vsync기능이 생긴 듯 했습니다. 중요한것은 AMD공식드라이버란 놈은 Vsync도 안 되어있던 놈이었는데 그 덕에 쓸모없이 성능을 깎아 먹고 있었습니다. 데스크탑 효과에 120fps이상 돌릴 이유는 없잖아요. 역시나 리눅스에서는 오픈소스 드라이버가 정답이었습니다. 훨씬 빠르고 쾌적해졌습니다. 그리고 Wine문제도 없습니다. 32비트문제도 한번에 해결 되었습니다. 이거야 원...갑자기 시원시원하니 속이 시원합니다.



60fps로 Vsync기능이 돌아가고 있음이 확인 된다. AMD 공식드라이버란 놈은 Vsync가 꺼진상태로 시스템을 괴롭히고 있었다.

벤치마크에서도 http://www.phoronix.com/scan.php?page=article&item=amd_apu_1310&num=1 제가 쓰는 Beema기반은 아니지만 80%정도 성능을 따라잡았다고 하니 오픈소스드라이버가 상당한 능력을 지닌 것은 맞습니다. 심지어 안정성은 이쪽이 더 좋습니다. Catalyst는 그냥 불안합니다. 가끔 마우스 포인터 깨지는 것도 예사입니다. 하지만 오픈소스는 역시 전혀 그런 문제가 없군요.


APU사용자 분들 바로 Kernel PPA에서 3.15이상의 커널로 업데이트 하신 뒤에 Oibaf PPA에서 업그레이드를 해보세요. 갑자기 지옥에서 천국으로 바뀝니다!!


Beema/Mullins기반 APU PC에서 ubuntu14.04 그래픽 드라이버 오픈소스로 사용하기


sudo add-apt repository ppa:oibaf/graphics-drivers

sudo apt-get update

sudo apt-get dist-upgrade


그리고 커널 업데이트

http://kernel.ubuntu.com/~kernel-ppa/mainline

여기서 제일 아래쪽으로 가서 원하는 커널 버전(3.15이상)을 찾아간 다음

32비트 버전 사용자는

linux-headers-~~~-generic~~_i386.deb

linux-headers-~~~all.deb

linux-image-~~~_i386.deb


이 3가지를 다운로드 받고


64비트 사용자는 


linux-headers-~~~-generic~~_amd64.deb

linux-headers-~~~all.deb

linux-image-~~~_amd64.deb


이 3가지를 설치하셔야 합니다.


,

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

분명 예전에는 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에서 비롯되었습니다.



 


 VS


 


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


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


sudo add-apt-repository ppa:lubuntu-dev/lubuntu-daily
sudo add-apt-repository ppa:gilir/q-project
sudo apt-get update
sudo apt-get install lxqt-metapackage lxqt-panel openbox


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


LXDE 그동안 고마웠어!

,

가상화라는 개념은 사실 예전부터 있었습니다. 하나의 컴퓨터를 여러대의 컴퓨터로 활용하는 것은 워크스테이션시절로 거슬러 올라갈 정도로 상당히 오래된 개념입니다. 하지만, 지금과 같은 거의 완벽한 가상화는 아니었고 그냥 이미 세팅이 완료된 시스템에 User가 일정 요금을 내거나 워크스테이션 관리자의 허락을 받고 사용하는 방식이었습니다. (윈도를 처음부터 쓰신 분들은 이해가 잘 안 되실 겁니다. 윈도는 사용자 개념이 워크스테이션에서의 그것과는 거리가 멀었기 때문입니다. NT계열 등장 이후에나 Unix의 개념과 비슷해졌습니다.)


즉, 워크스테이션에서는 사용자가 로그온을 하면 홈폴더(/home/사용자이름)에 한해서지만 내 컴퓨터처럼 사용할 수 있었습니다. 이 홈폴더가 샌드박스화 되면 일종의 가상화라고 합니다. 하지만 이는 이번에 이야기할 하드웨어 가상화하고는 이야기가 다르지요. 그 시절의 가상화는 소프트 가상화로 미리 설치된 OS에 설치된 프로그램만 사용할 수 있었던 시절입니다. 이 당시에 컴퓨터를 쓰고 싶은 사람들이 원하는 프로그램이 있으면 관리자에게 요청해야 했습니다. 정확히 하면 내 컴퓨터처럼 완벽히 사용할 수는 없었습니다.


하지만, 때는 흐르고 흘러서 1인 1PC시대가 도래했습니다. 옛날처럼 하나의 컴퓨터에 여러사람들이 붙어서 사용할 일이 없어졌고, 내 컴퓨터는 나만이 사용하는 것으로 바뀌었습니다. 그로인해 워크스테이션이란 개념은 점점 사라지게 되었습니다. 그도 그럴것이 개인용 PC의 성능이 워크스테이션을 뛰어넘기 시작하면서 옛날의 방식을 쓸 이유가 없어졌습니다. 이로써 한동안 가상화라는 개념은 사라지는 듯 했습니다. 하지만 아이러니하게도 개인용 컴퓨터에서 가상화라는 형식이 등장하게 될 줄은 몰랐을 겁니다.


그리고 바야흐로 90년대~00년대에 Apple사의 OSX가 등장하면서 PowerPC계열의 컴퓨터가 등장하게 됩니다. 당시에는 멀티미디어가 대세였는데 PowerPC는 이 방면에서 정말 강력한 컴퓨터였습니다. 게다가 Apple의 컴퓨터로써 이 PowerPC기반의 Mac은 기존 MacOS9를 쓰던 사람에게 큰 충격을 준 컴퓨터였습니다. 하지만 이 당시에도 PC는 Intel+Windows가 이미 잠식한 상황이었고 쓸만한 프로그램은 다 여기에 있었습니다. PowerPC를 쓰는 사람에게 이는 너무 아쉬운 점이었습니다.

"Mac에서 intel+Windows용 프로그램을 쓸 수 있으면 참 좋을텐데..." 이 작은 소원(?)은 VirtualPC라는 프로그램이 등장하면서 해결됩니다. 이 당시는 가상화라기보다는 intel칩을 흉내내는 에뮬레이터에 가까웠습니다. 하지만 VirtualPC가 Windows용으로 포팅이 되면서 기존 PC사용자에게 입소문을 타게 되었고, 가상화는 User모드 가상화에서 하드웨어 가상화라는 새로운 모습으로 격변하게 됩니다. 즉, 기존에는 이미 설치된 OS 환경에서만 내 맘대로 주무를 수 있었다면, 이제는 한정된 하드웨어이기는 하지만, OS도 마음대로 설치하고 프로그램도 마음대로 설치할 수 있는 새로운 가상PC가 만들어진 것입니다. 사실 혁명과도 같은 물건이었는데, Microsoft가 인수를 하면서 이 혁명과도 같은 물건은 한낱 후발 주자인 VMware에게 밀려버립니다.


하지만 모두 알고 계시듯이 VirtualPC나 VMware만 하드웨어 가상화지원을 하는 것은 아니었습니다. 그 이전에 리눅스에서 Xen이란 놈이 커널에 한해서지만 리눅스 가상화(반소프트 반 하드웨어 가상화)를 지원했고, Bochs와 Qemu라는 오픈소스 가상화 프로그램도 있었습니다. VirtualPC가 Microsoft에게 인수된 이후 CPU가상화 기능이 사라진(사라진 것은 아니고 PPC에서 intel칩을 에뮬레이션 해주지 못하게 되었습니다. 가상OS마저 Windows만 지원된것은 덤 입니다.)대에 비해 이 프로그램들은 CPU도 흉내를 내주어서 Arm이나 MIPS(!!)에서 Pentium을 흉내내준다던지 하는 누가 보면 신기한 일들도 했습니다.(스마트폰에서 Windows를 구동하는 영상의 대부분은 바로 저 Qemu나 Bochs를 이용한 것입니다.)하지만 성능은 상용프로그램에 비하면 좀 모자르기도 했고, VMware나 VirtualPC에 비해 잘 알려지지도 못했습니다.


현재 가상화의 선두주자는 누가 뭐라고 해도 VMware입니다. VMware하면 VMware Workstation만 생각하시는 분이 있을텐데 VMware의 주력제품은 VirtualBox나 VirtualPC와 같은 영역과는 차원을 달리하는 ESX입니다. 별건 아니고 그냥 VMware 가상화를 사용할 수 있는 환경을 갖춘 리눅스입니다. 하지만 이를 이용해서 옛날 워크스테이션 서비스 하는 것처럼 가상의 하드웨어 세트를 계정당 하나씩 제공 가능하게 해줍니다. 즉, 사라진줄 알았던 워크스테이션이 다시 돌아온 것이지요. 다만 옛날에는 다같이 쓰는 컴퓨터에 한 OS를 나눠 썼다면 지금은 완전히 가상화된 컴퓨터를 하나 덜렁 내주는 셈입니다. 이를 잘 쓴 서비스가아마존의 AWS가 아닐까 합니다. VMware사의 솔루션을 썼을지 아니면 자체 개발한 솔루션을 썼을지는 잘 모르겠지만 상당히 VMware ESX의 원하는 방향과 AWS는 비슷합니다. 가상화된 하드웨어에 미리 준비된 디스크이미지를 부팅하여 사용자에게 서비스한다... 이를 여러대 만들어서 클러스터화 하면 실제 기기는 몇대 안 되더라도 서버가 여러대 있는 듯한 효과를 만들어내게 됩니다. 워크스테이션의 강력함이 이렇게 쓰이는 셈입니다.


얼마전에 보니 VirtualPC를 말아먹은 Microsoft는 Hyper-V란 놈을 내놓고 VMware ESX를 노리고 있더군요. 실제 성능을 보아하니 VMware보다 더 좋기는 하던데 아마도 Windows만 지원하다보니 최적화가 되어서 그럴 것이라는 생각이 듭니다. 공짜라고 좋다고 쓰시는 분이 있던데 그거 공짜 아닙니다. Windows의 Pro버전이 비싼 이유가 다 거기 있는 것입니다. 게다가 Windows는 Unix만큼의 안정성을 갖추지 못했습니다. (단 유닉스에 비해 리눅스는 좀 불안정한 감이 있습니다. 안정성을 추구하는 Debian리눅스하고 비교해도 그렇습니다.)그런데 Hyper-V가 오직 Windows만 지원되다 보니 메리트가 상당히 떨어집니다. 아무래도 Hyper-V에 대한 글을 볼때마다 씁쓸한 생각이 드는 것은 어쩔 수 없군요. VirtualPC시절만 해도 상당히 좋은 프로그램이었고 발전가능성이 무궁무진했었는데 거대기업에 먹히고 나서.....


그러고보니 VMware나 VirtualPC(현재 Hyper-V)에 맞서는 오픈소스 종족이 남아 있습니다. Oracle에서 지원하는 VirtualBox입니다. 이것은 innotek시절부터 성능이 마음이 들어서 상당히 많은 사람들이 사용하고 있습니다. innotek이 Sun사에 인수되면서 성능이 안정화 되었고 Oracle에 Sun사가 인수되면서 잠시 불안해 했었지만 Oracle이 별 터치를 안 해주면서(?)지금은 GPU가상화도 그럭저럭 해주는 물건이 되었습니다. 문제는 VMware에 비하면 부족한 디스크I/O입니다만, 이는 시간이 지나 하드웨어 성능이 무섭도록 발전하면 격차가 알아서 좁아질 운명입니다. 다만, Oracle은 VMware같이 ESX같은 솔루션을 준비할 생각이 없는 것 같습니다. 하지만, 어쨌건 가상화는 가상화, 그것도 VMware에서 사용하는 것과 비슷한 하드웨어 가상화 입니다. 좀 설정만 해주고 http등의 알려진 프로토콜로 묶어주면 ESX못지않은 시스템을 갖출 수는 있습니다. 다만, 상당히 설정이 귀찮고 ESX에 비해 성능이 영 좋지 못하다는 것이 문제이기는 합니다.


지금 현재 가상화 대결의 구도는 VMware vs VirtualBox (vs Hyper-V - 일부에만 해당 Linux/Unix는 지원이 안 되므로)입니다. 하지만 Arm칩이 여기저기 쓰이는 요즘 Qemu나 Bochs도 무시 못합니다. 가상화는 아직 발전 중이고 워크스테이션은 다시 세상의 대세가 될 수 있을까요? 그 것은 조금더 상황을 봐야 할 듯 합니다.

,

LinuxMint는 주력 환경이 MATE와 Cinnamon 환경입니다. 이 두 환경은 GTK기반으로 만들어졌다는 특징이 있습니다. (GTK2와 GTK3라는 기반 버전의 차이가 있기는 하지만) 리눅스의 그래픽라이브러리는  GTK외에 QT도 있는데 자세한 이야기는 http://moordev.tistory.com/9 여기를 읽어보시면 알 수 있습니다. 또 다른 라이브러리인 QT기반 데스크탑 환경으로는 KDE가 대표적입니다. 아니, GTK기반은 정말 많지만 QT기반은 KDE가 독보적입니다. 하지만 KDE환경에서 GTK어플리케이션 안 돌아가는 것 아니고, Gnome(GTK기반 환경의 대표적이지요)환경에서 QT어플리케이션 안 돌아가는 것 아닙니다. 그런데 문제는 Gnome 어플리케이션이나 KDE 어플리케이션이라 불리우는 해당 데스크탑환경에 종속된 어플리케이션은 해당 데스크탑 환경이 갖춰져야 합니다. 안 그러면 정상적인 동작이 보장이 안 됩니다.


대표적인 Gnome어플리케이션은 Nautilus가 있습니다. KDE종속 어플리케이션으로는 Konqurer가 있습니다. 둘 다 탐색기로는 으뜸으로 쳐 주는데, KDE에서 Nautilus를 설치하려고 하면 Gnome을 설치하려고 하고 Konqurer를 설치하려고 하면 KDE를 설치하려고 드는 것을 알 수 있습니다. 사실 이 프로그램은 해당 데스크탑 환경의 자원을 일부 사용하기 때문입니다. Xfce나 LXDE는 대부분 어플리케이션이 종속적이지 않습니다. 그냥 GTK만을 사용한다고 생각하면 편한 수준의 어플리케이션입니다. 만약 MATE나 Cinnamon을 사용한다면 GTK기반 환경이니 당연히 GTK는 설치되어 있을 것이고, LXDE나 Xfce의 어플리케이션(Leafpad나 Thunar 같은 프로그램)을 무리없이 사용 할 수 있습니다.


하지만 KDE는? MATE환경에서 실행 물론 가능합니다. QT만 설치하면 일단 실행은 됩니다. 문제는... 인터페이스가 깨지고 정상적으로 동작을하지 않습니다. Kdenlive를 자주 애용하기 때문에 LinuxMint MATE환경에서 kdenlive만 설치해봤더니 인터페이스가 엉망이 되어서 실행 되더군요. 저는 새로 나온 버전인줄 알았습니다. 하지만 자세히보니 그것이 아니더군요. 결국 KDE를 깔아야 하나...싶었는데 KDE를 완전히 다 설치할 필요는 없다고 합니다. 즉, KDE의 베이스시스템만 설치하면 KDE어플리케이션을 다른 환경에서 실행하는데에는 아무런 지장이 없습니다.


서론이 길었네요. KDE어플리케이션을 GTK기반 환경에서 정상적으로 실행을 하기 위해서는 다음과 같은 명령어 한 줄이면 필요한 환경을 다 설치해 줍니다.


sudo apt-get install systemsettings


이거면 필요한 KDE프로그램 전부를 다 설치해 줍니다. 이렇게 하면 KDE설정 프로그램하고 KDE 환경베이스만 따라와서 추가 데스크탑환경 설정 따윈 없고, 그냥 KDE어플리케이션을 정상적으로 동작 할 수 만 있게 됩니다.


여기서 한국어 사용자 분들은 한가지 생각해야 하실 것이 있는데, 한국어 사용자는 ibus가 자동적으로 따라옵니다. Uim이나 Nabi사용자 분들은 다시 입력기 설정을 해주셔야 합니다. KDE설정 프로그램이 자기 멋대로 입력기를 바꿔 버립니다. 참고하세요.

,

컴피즈는 리눅스 데스크탑을 아주 멋진 효과로 쓰는 맛이 있게 만들어주는 정말 고마운 도구입니다. 우분투에서도 8.04부터 기본 탑재해왔고, (그 전에는 저장소에는 있었지만 따로 설치를 해줘야 했습니다.) Unity인터페이스를 굴리는데 쓰이고 있습니다. 하지만 Unity는 컴피즈를 그냥 창관리자로만 쓰고 있어서 컴피즈의 다양한 효과를 쓰려면 이리저리 삽질을 해야 합니다.

 그래서일까요? 우분투가 Unity를 탑재하기 전의 모습과 흡사한 리눅스민트(특히 MATE버전)에서는 Compiz Config Setting Manager(통칭 CCSM-컴피즈 설정 관리자)를 기본 탑재하고 데스크탑 설정에서 클릭 한방으로 컴피즈를 쓸 수 있게 배려해 놓았습니다. 우분투도 10.10까지만 하더라도 설정-모양에서 바로 컴피즈를 켤 수 있었고 이는 삽질이 동반되었던 다른 배포판에 비해 참 유용했었습니다. 하지만 Unity를 탑재하기 시작하던 11.04부터 컴피즈설정이 삽질이 되기 시작했고 상당히 짜증나는 작업이었는데 리눅스민트에서 이를 다시 클릭 몇번으로 할 수 있게 해 주었네요.


14.1.8 현재 리눅스민트 17.1(MATE)에서 컴피즈를 쓰는 법은 다음과 같습니다. 아주 간단합니다.


메뉴-기본설정-데스크탑 설정으로 들어갑니다.

그리고 창 탭을 클릭하고 다음과 같이 설정합니다.


저는 지금 컴피즈가 설정이 되어있어서 이렇게 되어있지만 기본은 마르코로 되어있을 겁니다. 그러면 여러가지 옵션들이 즐비한데 컴피즈로 바꾸면 딱 이것만 뜨게 됩니다. 그럼 나머지 옵션은 어디서 하냐구요?

컴피즈 설정 관리자(일면 CCSM)으로 하시면 됩니다. 여기서 각종 효과와 비기(...)등을 쓰실 수 있게 됩니다.



다른 효과는 몰라도 저 창 출렁거림효과는 중독성이 상당히 강하다. 괜히 창을 흔들어 보고 싶을 정도

민트메뉴-설정에 가보시면 CompizConfig Setting Manager라고 있습니다. 이게 바로 컴피즈 설정 관련프로그램인데 여기서 이것저것 건드리다보면 데스크탑이 엄청 느려(...)지는 경험을 하실 수 있습니다. 물론 컴피즈니까 GPU가속은 필수입니다. 하지만 쓰다보면 중독 될 정도로 컴퓨터를 쓰는 맛이 있습니다. Unity도 괜찮은 인터페이스지만 전 반쪽짜리 컴피즈보다는 전부 다 쓸 수 있는 MATE용 컴피즈가 상당히 마음에 듭니다. 아니 이게 진짜 컴피즈이지요. 다른 것은 몰라도 애니메이션 설정하고 창출렁거림 옵션은 꼭 켜두시길 권장합니다. 나중에는 출렁거리지 않으면 이상하다고 느껴질 정도입니다. 데스크탑 큐브도 좋지만 가상 데스크탑을 적극적으로 쓰지 않는다면 볼 일이 없는 것이 함정입니다.


어쨌건 리눅스 민트 쓰신다면 컴피즈를 켜는 것을 추천합니다.


P.S 스텝매니아를 하신다면 컴피즈 설정에서 Composite에 Stepmania를 제외 시켜주시는 것이 좋습니다. 보니까 프레임이 현저히 떨어집니다.


방법은 다음과 같습니다. CCSM에서 Composite를 누르고


Unredirect Match부분에서 위 그림과 같이 내용을 추가해주시면 됩니다.

,