Linux가 발전한 것은 Opensource라는 것이 매우 중요한 점이었습니다.

BSD계열도 Opensource로 발전했습니다.

Firefox도 Netscape의 소스 공개를 기반으로 약 5년~10년동안 리브랜딩을 했습니다.

Blender는 오픈소스를 무기로 3대 3차원그래픽 모델러의 하나가 되었습니다.(3대 모델러중 유일한 무료 프로그램입니다.)

OSX의 mach커널은 본래 오픈소스였고 지금도 오픈소스입니다.

Wine은 기어코 Windows의 API를 다른 OS에 호환하는데 성공했습니다.

OpenTTD는 본래 Transport Tycoon이란 게임의 리버스 엔지니어링이지만 지금은 다른 게임이라고 해도 될 수준입니다.

Arduino는 소스만 공개한 것이 아니라 하드웨어의 설계도를 공개함으로서 수없이 많은 변종들을 만들어내었습니다.

오픈소스는 이처럼 많은 것들을 이룩했습니다. 심지어 걔중에는 본래 유료 상용프로그램이었지만 오픈소스로 전환해서 성공한 계열도 있습니다. 소스코드의 공개는 정말 무시무시한 파급력을 지녔다고 할 수 있습니다.

위에서 보시면 Wine의 이야기가 있는데 Wine은 정말 무시무시한 결과라고 할 수 있습니다. Microsoft가 공개한 API의 형태(Microsoft 기술 문서 보면 다 나와있습니다. API를 알아야 이걸 쓸지 말지 알 터이니...)와 이를 호환하는 API를 만들어서 X와 콘솔 화면에 뿌린다는 생각으로 출발했습니다. 그리고 지금은 성공한 프로젝트이며 지속적으로 진행되어야 하는 프로젝트가 되었습니다. 지금은 MSOffice 3총사(Word, Powerpoint, Excel)를 별 삽질없이도 굴릴 수 있을 정도로 상당히 안정화 되었고 저도 덕분에 잘 쓰고 있습니다.

Wine으로 실행한 Excel 너무 잘 굴러간다.

다만....Wine은 유닉스 환경에 호환되게 돌아가게 하기 위해 몇가지 변칙이 적용되었습니다. 대표적인 것이 X환경이 기본적으로 돌아가며 GCC기반이어야 한다는 것이 전제입니다. GCC야 본래 C표준을 따르는 것이니 문제가 전혀 없지만(심지어 Clang을 써도 됩니다. C표준이라..) X환경이 전제되기 때문에 Wine은 X가 돌아가야 제대로 돌아간다는 의미가 됩니다. 그리고 단순히 응용프로그램이 굴러가는 것에 의미를 두기 때문에 Windows커널에 직접붙는 장치들은 호환이 되지 않습니다. 대표적인 것이 보안동글입니다. 해당 동글은 값비싼 프로그램에서 주로 사용하는데, 드라이버가 당연히 Windows만 있습니다.(Windows용 프로그램이니 당연히 Windows 드라이버만 있습니다.) 이런 프로그램은 Wine에서 굴릴 때 당연히 문제가 생깁니다. 

그러면 이렇게 생각해 볼 수 있습니다. Wine에 드라이버까지 붙이려면 Windows 커널까지 구현해야하나? 그럼 처음부터 Windows의 호환커널부터 만들면 어떨까?

 네 이런 생각과 가장 흡사한 프로젝트가 ReactOS입니다.

https://reactos.org/

2016년 3월에 0.4버전이 드디어 릴리즈 되었습니다. 0.3버전이 2001 2006년 즈음에 나왔던 것으로 기억되는데 참 오래되었습니다. 사실 이 프로젝트는 98년 시작(!)되었습니다. 네 98년이요. Windows95~98이 나왔던 바로 그 시절입니다. Windows98가 어떤 OS였는지 아신다면 ReactOS가 무엇을 노리고 나왔던 것인지 알 것입니다. Windows95가 일대의 파란을 일으키고 있을 때 호환 OS를 목표로 했던 것입니다. 즉, Wine보다 역사가 더 오래되었습니다. 단순 API호환이 아닌 커널부터 만드는 것을 감안하면 이해가 됩니다.

현재는 NT커널을 호환하는 것을 목표로 하고 있고 0.3버전은 WindowsXP시절에 나왔으니 XP의 드라이버 호환을 목표로 했습니다. 지금은 아마도 Windows커널 6~혹은 Windows커널 10의 호환을 목표로 하고 있을 겁니다.

참고로 0.4버전도 아직은 Alpha 단계입니다. Wine도 beta딱지를 10년동안 달고 있었으니 아직까지도 알파를 달고 있을만합니다. 덕분에 아직도 100% 장치 호환은 꿈도 못 꾸고 있습니다. 하지만 Wine과 같은 일반 응용프로그램 호환은 그럭저럭 가능한 수준까지 올라왔습니다. 그도 그럴것이 API단계에서는 Wine의 코드를 수혈받았다고 하네요. 그래서 DirectX를 직접적으로 구현을 못하고 있고 Wine의 D3DtoOGL기능을 써서 OpenGL로 구현하고 있습니다. 그나마도 드라이버문제로 잘 안 됩니다. 추후 ReactX프로젝트로 DirectX호환 프로젝트도 계획되어있고 0.5버전은 Beta단계로 나아갈 예정이라고 하니 기대되는 대목이라고 할 수 있습니다.

다만 써본 결과...Alpha단계라 아직은 실사용으로는 무리입니다. 하지만 응원할 수 밖에 없는 프로젝트인 것은 확실합니다. 무료버전의 Windows가 나오는 것이라고 봐도 상관 없고 OpenTTD가 새로운 녀석이 된 것처럼 ReactOS도 Windows와 호환성을 갖춘 새로운 물건이 될 테니까요. FreeDos가 MS-Dos와 호환을 갖추었고 Linux가 Unix와 호환을 갖추었듯이 ReactOS도 이런식으로 호환을 갖추어서 발전 할 겁니다.그리고...새로운 OS가 될 수 있을 겁니다. 그러면? IT의 발전이 또 한번 이루어 지는 겁니다. 우리가 지금까지 봐온 것처럼 말이지요.

 MATLAB은 공대에서 제어공학이나 전자공학을 한다면 한번쯤은 써보는 물건입니다. (요새는 영상처리나 음성학에서도 사용하고 경제학에서도 사용합니다. 그냥 수학하고 관련있으면 다 씁니다.)공학에서 사용하는 수학을 미리 함수화해 놓았고 코드도 그리 어렵지 않으며 배우기도 굉장히 쉬워서 여기저기에서 사용하고 있습니다.

 무엇보다 MATLAB은 학생들에 한해 평가판을 쉽게 제공해줍니다. 사실 학생인지 확인도 안하고 그냥 평가판을 제공한다는 느낌이지만 학생들이 졸업하고나서 연구소에서 MATLAB을 쓸 것이라고 예상한다면 이는 좋은 마케팅수단이 될 것이라는 것은 예상이 가능합니다.

 최신의MATLAB은 한글 지원이 상당히 잘 됩니다. 별 다른 설정없이도 한글입력이 되고 한글을 읽는데에 문제가 전혀 없습니다. 2010버전만 하더라도 폰트문제와 인코딩 문제로 황당한 경우를 많이 겪었는데 거의 해결되었더군요. 문제는 이거 윈도우에서는 그동안 이런 문제가 전혀 없었다는겁니다. 사실 대다수 MATLAB사용자들은 윈도우를 사용하니 한글문제에 관해 몰랐을 겁니다. 이런게 있었어? 하는 수준이었겠지요. 하지만 리눅스나 OSX에서는 한글문제로 골치아픈 적이 많았습니다. 게다가 X의 가속문제로 3차원 그래프를 그리는데 애로사항이 꽃피었습니다. 지금도 이 문제는 현재 진행형이라 AMD그래픽사용자들을 소프트웨어 렌더링방식으로 그래프를 표현합니다.

 MATLAB과 언제나 함께하는 Simulink는 MATLAB이 걸어온 길을 아직도 못 왔습니다. 한글문제가 아직도 있더군요. 모델파일 저장하는데 한글이 경로에 끼여 있으면 저장이 안 됩니다. UTF-8인코딩으로 저장하면 보통은 정상적으로 동작해야 정상인데 이 놈의 물건은 그게 안 됩니다. 나보고 어쩌라는 건지... 윈도우에서는 잘 되는 듯 합니다. 혹시모르니 한글을 빼라고는 하지만 유니코드 지원이 이렇게 부실해서야 이거야 원.(원래 유니코드가 나오기 전부터 만들어진 물건이기는 합니다. 그래도 1년에 두 번이나 버전업을 하면서 이렇게 까지 부실한것은 좀...)

리눅스 지원을 해준다는 점은 감지덕지 하지만 계속 이런식이면 Scilab이나 Numpy를 밀어붙여서 가는 수도 있습니다. 사실 이미 Scilab은 고려했다가 ToolBox 일부가 부실해서 MATLAB으로 회귀한건데 호환성면에서는 Scilab이 훨씬 낫네요. 우리나라나 중국,일본도 MATLAB을 많이 쓰는 것으로 알고 있는데 윈도우버전만 이를 제대로 하는 걸 보면 리눅스사용자들은 무시당한다는 느낌이 계속 드네요. 마이너한 나라에서 마이너한 OS 쓰는 서러움이 느껴지네요. 한국지사에서 신경을 써줬으면 좋겠는데 이 나라에서 마이너OS를 신경이나 써줄까요?

정 안 되면 MATLAB을 안 쓰는 것도 방법이 될 수도 있겠네요. scilab이나 배워볼까....

아무래도 요즘은 원격데스크톱을 통해 일을 보는 경우가 많아 졌습니다. 직장이나 학교에 서버를 하나 열어두고 어디서나 그 컴퓨터를 이용해서 일을 하는 것이지요. 덕분에 쉬는날에도 일을 하는 뭐 같은 경우도 늘었다고 하지만 편리한 기능인 것은 사실입니다.

본래 원격데스크톱은 여러가지 프로그램들이 있습니다. 그중 제일 유명한 것은 VNC이고 MS에서 만든 RDP 프로토콜 등이 있습니다. 본래 유닉스의 GUI로 유명한 Xfree86도 워크스테이션의 원격 데스크톱을 위해 만들어진 프로토콜이지만 이쪽은 아무래도 나온지도 오래되었고 호환성도 그닥이라 NX등의 대체 프로토콜로 대체되었고 지금은 그냥 로컬 GUI를 위한 녀석 정도로 이용되고 있습니다. (그나마도 Wayland로 대체 중입니다.)

VNC와 RDP는 그놈의 성능 때문에 참 말이 많았는데요. 압축 기술과 통신 기술의 발전은 이들을 충분히 쓸만하게 만들어 주었습니다. VNC는 윈도우보다는 리눅스나 OSX서버로 접속하는 것이 좋았고 윈도우 서버에서는 기본으로 포함되어있는 RDP가 성능이 잘 나왔습니다. (원격데스크톱은 직접 돌아가는 서버의 성능이 더 중요하기 때문입니다.)

그럼 리눅스에서 RDP로 윈도우에 접속하는 것은 어떤것이 있을까요? 리눅스에서 RDP프로그램은 대략 다음과 같습니다.

xrdp

rdesktop

freerdp

remmina

이중 xrdp는 X를 RDP로 뿌려주는 서버프로그램입니다. 따라서 윈도우에 접속하는 것이 아닌 리눅스에 접속하게 만드는 프로그램이니 일단 목록에서 제외합니다.

rdesktop은 XP시절 꽤나 유명했던 프로그램입니다. 많이 이용되었지만 업데이트가 어느순간 중단되었습니다. 하지만 안정성 하나 만큼은 매우 좋습니다. RemoteFX(원격에서 3차원 가속을 사용하는 기술)가 안 되는 것이 흠이라면 흠입니다.

remmina는 GTK기반으로 GUI로 구성되었다는 것이 장점입니다. VNC와 SFTP등도 지원하는 다방면 프로그램입니다. 렘미나에 대해서는 다음에 알려드리겠습니다. 사실 설명없어도 잘 쓸 수 있게 UI 설계가 잘 되어있습니다.(그런데 RemoteFX가 잘 안 되는 듯 합니다.)

그리고 남은 하나는 오늘의 주인공 FreeRDP(http://www.freerdp.com/) 입니다.

써 본결과 100Mbps 짜리 유선랜 환경에서 딜레이가 거의 없던 것을 확인했습니다. rdesktop은 RemoteFX가 안 되어서 그런가보다 했는데 윈도우-윈도우 환경에서 써본결과 FreeRDP보다 성능이 떨어지는 모습이 보였습니다. 어찌보면 원조를 뛰어넘은 셈입니다.

다 필요없고 한번 써보고 싶다고 하시면 바로 어떻게 쓰는지 알려드려야겠지요?

우선 서버인 윈도우에서 접속을 할 수 있게끔 허용해야 합니다.

윈도우에서 시스템 설정-고급 시스템 설정에 들어가신 뒤 원격 탭에서 다음과 같이 설정해 주셔야 합니다.

원격접속을 하겠다면 무조건 허용하자. Windows에서는 VNC보다 RDP가 낫다.

일단 원격 접속을 허용해주셨다면 이제 우분투에서 FreeRDP를 설치합시다.

기본 저장소에도 FreeRDP가 있지만 최신 판을 써주셔야 성능이 잘 뽑히기 때문에(RemoteFX와 GFX기능 때무입니다.) PPA를 이용해서 설치하도록 합시다. 

sudo add-apt-repository ppa:remmina-ppa-team/remmina-next

sudo apt-get update

sudo apt-get install freerdp

이러면 freerdp-x11이란 패키지를 대신 설치한다고 나옵니다. 보통은 X환경을 사용하니 이게 맞는 겁니다.

그리고 접속을 해주시면 되는데 이게 좀 골 때립니다.

오로지 명령으로 때우기 때문입니다.

터미널에서 다음과 같이 명령을 내려주셔야 합니다.

xfreerdp /v:[서버IP] /u:[Windows 사용자이름] /p:[암호] /gfx /rfx /bpp:24 /w:1280 /h:720 /compression

일단 이것은 예시입니다. 다른 옵션은 다 빼버려도 되는데 /v: 하고 /u: 옵션은 꼭 넣어주셔야 합니다. /p: 는 암호인데 필요하면 물어보기는 합니다.

일단 이것으로 접속이 되기는 합니다. 그런데 엄청 버벅일 겁니다. 당연하게도 뒤에 있는 옵션이 이를 해결해주는 옵션이라 저 옵션도 거의 필수가 되었습니다.

걔중 /bpp: 옵션은 색상입니다. 성능이 딸린다 싶으시면 24대신 16을 써도 됩니다. 성능이 남아도시면 32도 괜찮습니다. /w:하고 /h:는 화면 크기입니다. 클라이언트의 모니터보다 크면 당연히 안되겠지요. 저는 720p(HD)크기를 썼는데 크기는 마음대로 하셔도 상관없습니다. 대충 필요한 만큼 적당히 써주시면 됩니다.

/rfx

/compression

/grx

이제 이 옵션들이 관건인데요.

/rfx :  remoteFX 옵션으로 원격서버에서 3차원 가속이 가능토록 해줍니다. 이제는 필수가 되었습니다. Windows8에서 가속을 안하니 메트로화면이 버벅버벅...

/compression : 말그대로 압축을 하는 겁니다. JPG나 H.264로 압축하는데 네트워크 마비되는 것 보기 싫으시면 당연히 해주시는 것이 좋습니다.

/gfx : 아직 실험적인 기능이지만 성능 향상폭이 엄청 좋습니다! 클라이언트단에서 하드웨어 가속을 사용하는 옵션입니다. 동영상 같은 것이 버벅이지 않고 잘 나오게 하는데 필수적인 옵션입니다.

이외에도 /sound 옵션등이 있는데 man xfreerdp 명령을 통해서 알아보는 것을 추천합니다.

이제 보셨으면 아시겠지만 GUI가 아니라 상당히 불편합니다. 일일이 저걸 다 적어주는 것도 일입니다. 그래서 https://github.com/Gibbio/RDPGUI 여기에서 Rdesktop이나 FreeRDP를 위한 GUI도구를 제공합니다. 이런 것이 있다면 이용해주는 것이 맞겠지요?

자 그럼 FreeRDP+ RDPGUI를 써봅시다.

https://github.com/Gibbio/RDPGUI/archive/master.zip

위 링크를 통해 스크립트를 받도록 합시다. 그러면 다음과 같이 파일들을 볼 수 있습니다.

rdpgui.py 요놈과 rdpgui.ini 요놈이 우리의 핵심이다.

우선 rdpgui.py에 실행 권한을 주셔야 합니다. 오른쪽 버튼을 누르고 속성에 들어가서 권한을 다음과 같이 줍니다. (탐색기 프로그램마다 다릅니다.)

명령으로 때울라면 sudo chmod +x rdpgui.py

그리고 rdpgui.ini 파일을 수정합니다. 기본적으로 이 프로그램은 라즈베리파이를 위해 만들어진 것이라 기본 설정이 Raspbian에 맞게 되어있습니다. 하지만 수정하면 그만입니다.

여러가지 수정할 곳이 좀 많습니다. 저는 다음과 같이 수정했습니다.

RDPServer는 당연히 접속하고자 하는 서버 IP이고 RDPExtraFlags는 위에서 썼던 명령줄을 적어놓은 것입니다. 위에서 설명 안 했던 sound 옵션도 추가했습니다.

/usb 옵션도 추가해 넣었는데 이건 무슨 문제인지 작동을 안 한다. 아마도 권한 문제가 아닐까 생각한다.

그리고 rdpgui.py를 실행하면?

짠! 이제 사용자 계정과 암호를 넣고 접속을 해주시면 됩니다. 옵션을 미리 저장해 놓았기 때문에 Windows의 원격데스크톱 쓰는 마음으로 쓰시면 됩니다.

윈도우즈에 접속이 완료되었습니다. 그래픽가속도 잘 되니 마음껏 쓰시면 됩니다!