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

RHEL과 CentOS이야기는 리눅스쓰시는분들이라면 잘 아실겁니다.

RHEL은 전세계에서 가장 인기있는 대규모 서버용 배포판이고 안정성도 충분히 검증되어왔습니다. 그리고 그 안정성을 바탕으로 기술지원등의 수익을 벌고 있습니다.
그리고 대한민국한정으로 리눅스로 밥벌어먹을때 익혀야할 필수 배포판입니다.(우분투는 대한민국에서 아쉽게도 이쪽에서 크게 힘을 못 씁니다)

그리고 CentOS는 이 RHEL과의 호환성을 보장하고 무료로 배포된 배포판이기에 RHEL쓰다가 CentOS로 바꿔도 쓰던거 그대로 쓸 수있을 정도로 RHEL과 호환성이 좋기에 굳이 기술지원이 필요없다면 개인차원에서도 RHEL공부용으로 쓰기 좋은 배포판이었습니다. 그리고 국내에선 네이버나 카카오같은 자체개발능력이 있는곳에선 CentOS를 주력으로 쓰고있었지요.

그러다 CentOS를 직접 레드햇이 인수하게 되는데 이때까진 그래도 괜찮았습니다. 호환성을 무기로 점유율을 늘린건데 호환성이 더 좋아지면 더 좋아졌지 개판이 될거라고는 생각못했으니까요.

하지만 레드햇은 CentOS의 목을 쳐버리고 말았습니다.
기존 CentOS의 지원기간을 줄이고 이후에는 CentOS Stream이라는 개발버전만 남기기로 했습니다.

CentOS Stream은 RHEL과 호환되지 않습니다. RHEL은 안정성이 검증된 특정버전을 꾸준하게 보안업데이트만 하면서 지원해주는것이 특징인데 CentOS Stream은 말그대로 Debian unstable마냥 굴러가거든요.
Debian unstable과 stable이 일부 라이브러리에서 서로 충돌나는것처럼 CentOS Stream과 RHEL은 충돌납니다.

이후 CentOS의 후신을 자처하며 Rocky가 등장했고 Oracle도 CentOS에서 넘어올 수있도록 스크립트까지 배포하며 열심이었는데 레드햇은 이 Rocky도 마음에 안들었는지 유료 구독자 이외에는 자신들의 소스접근을 차단하기에 이르렀습니다. (호환성을 얻기위해선 소스를 알아야겠지요. 이걸 못 하게 막은겁니다.)

레드햇이 리눅스 개발커뮤니티에서 끼치는 영향을 생각하면 이건 상당히 위험한 행보입니다. 당장 RHEL의 점유율에는 영향이 없겠지만 (아니, 오히려 RHEL의 점유율은 올라갔습니다) 이미 개발자들에게 찍혀버렸고 CentOS로 RHEL관리법을 배우던 학생들도 사라져버렸습니다.

보통 CentOS로 공부하던 사람들이 현장에서 RHEL을 쓰는 방식으로 점유율이 높아진건데 이들이 사라지고 말았으니 이후 미래는 조금 위험해지지 않았나 싶습니다.

P.S RHEL의 소규모버전은 무료로 풀었다고 합니다. 학교등의 소규모 서버는 이걸로 한다고쳐도 규모있는 중견기업은 어떻게 해야할까요? RHEL을 구독해야할까요?

모르는 분들은 모릅니다
VKD3D vs. DXVK

사실 이 둘은 경쟁관계라고 볼 수 있습니다
VKD3D는 Wine환경에서 D3D를 Vulkan으로 돌리기위해 만들어진 라이브러리이고 DXVK는 DirectX환경에서 D3D를 Vulkan으로 돌리기위한 라이브러리입니다

이렇게보면 둘이 직접경쟁하는것 같지 않을겁니다. 하지만 이 둘은 경쟁중입니다. 바로 SteamDeck에서 구동하는 방식이지요.

저 위에 문구에서 D3D를 Vulkan으로라는 문구가 겹치는것이 보일겁니다. 사실 이게 이 둘의 핵심입니다만 구동방식이 약간 다릅니다.

DXVK는 DirectX환경. 즉, 윈도우환경을 전제로 합니다. 그런데 Wine은 윈도우와 호환되는 환경이기에 Wine에서도 구동이 이루어졌습니다.
VKD3D는 Wine환경에서 구동이 전제이고 실제 윈도우에서 구동되는건 신경쓰지 않았습니다.

그럼 SteamDeck에선 어떨까요? 당연히 SteamDeck은 네이티브 리눅스용이 아니면 Proton으로 구동되고 이는 사실 게임에 최적화된 Wine입니다. 그러다보니 DXVK나 VKD3D를 쓰게 되었고 둘이서 성능에 관해 경쟁하게 되었습니다.

써본결과 둘 다 성능차이는 크게 없지만 특정게임에 한해 DXVK가 더 낫기도하고 VKD3D가 더 낫기도하고 그렇습니다. 이는 D3D11을 Vulkan으로 구동하냐와 D3D12를 Vulkan으로 구동하냐의 차이입니다. D3D12를 잘쓰는곳은 VKD3D가 훨씬 성능이 좋지만 D3D12보다 D3D11이 더 괜찮은 게임은 DXVK가 더 나은 상황입니다.

그리고 계속 SteamDeck이라고 하고 있지만 일반PC리눅스의 스팀도 동일한 방식을 쓰고 있으니 같은 방식 차이가 생길거라는 생각을 할 수가 있습니다.

밸브의 선택은
DirectX11은 DXVK
DirectX12는 VKD3D로 잡은것 같습니다만 모르지요. 나중엔 어떻게 될지...

참고로 DXVK는 윈도우환경을 전제로 했기에 DirectX11에서 느린게임(라데온이 보통 그렇습니다)을 Vulkan으로 구동해서 빠르게 구동할 수 있지만 VKD3D는 윈도우에서 구동을 보장하고 있지 않습니다. 이쪽은 애초에 리눅스나 유닉스에서 돌리는것으로 만든 Wine팀 작품이니까요.

결국 우분투에서 데비안으로 넘어갔습니다. 이쯤되니 우분투 분투기라는 블로그 이름하고 달라져버렸지만 어찌되었든 우분투를 안 쓰는건 아니기에 (업무상 써야합니다.) 이름을 바꾸지는 않을 겁니다.
 
처음 데비안으로 바꾸고 나서 고생한것이 LighDM이 불편하다는 것이었습니다.
 
우분투는 사용자 리스트가 있고 여기서 고른다음 비밀번호만 치면 되는 구조였는데 데비안은 사용자 이름도 치고 비밀번호도 처야 하는 구조더군요.
 
왠지 윈도8 시절의 로그온 화면같은 느낌?
 
하지만 LighhtDM설정만 바꾸면 될 일입니다.
 
우선은 관리자 모드로 전환합니다. root 계정이지요.  root로 로그온 하거나 sudo -s 명령으로 루트모드로 들어갑니다.
/etc/lightdm/lightdm.conf.d/  폴더에 (없다면 만듭시다) 50-myconfig.conf 파일을 만듭니다. 사실 파일명은 무엇이든 상관없습니다. 그냥 나만의 세팅이라는 이름하에 쓰는 것이지요.
 
sudo nano /etc/lightdm/lightdm.conf.d/50-myconfig.conf
 
그리고 다음 내용을 채웁니다.
[SeatDefaults]
allow-guest=false
greeter-show-manual-login=true
greeter-hide-users=false
 
이제 재부팅 하면 우분투처럼 사용자를 리스트에서 선택하는 식으로 바뀝니다. 편하죠.

https://betanews.com/2019/04/01/linux-mint-depressed/

리눅스 민트는 제가 사용하는 배포판이고 우분투 기반으로서 상당히 좋은 대중적인 배포판입니다. 그리고 매우 편리하고 원본인 우분투보다 더 뛰어난 모습을 보이고 있기에 누군가에게 리눅스 배포판을 추천한다면 바로 추천할 수 있는 물건입니다.

실제로 한국에서 제작되는 하모니카 프로젝트도 리눅스민트를 기반으로 하고 있습니다.

그러나 지금 메인개발자인 Clem은 이것저것 문제가 많은 것으로 보입니다. 후원금 문제도 있고 개발자를 모으는 것도 쉽지 않은 것으로 보입니다. 심지어 유능한 개발자가 2명이나 나갔다고 하네요.

https://blog.linuxmint.com/?p=3736

여기만 보면 상당히 실망을 한듯한 모습이 보입니다. 특히 웹사이트 재편과 로고 제작에 대해서도 여려워 하는 듯 합니다. 그리고 리눅스 민트가 사용하는 윈도우 매니저 개발자와도 사이가 썩 좋지 않을 수도 있는 듯 합니다. 물론 이 경우에는 다른 윈도우 매니저로 갈아타면 그만이긴 합니다. 혹은 민트팀에서 자체 제작하는 것도 방법입니다. (가뜩이나 개발자가 부족하다고 하는것이 문제긴 합니다.)

아무튼 19.2 Tina 가 곧 나온다고 했지만 생각보다 오래 걸릴 수도 있고 어쩌면 더 힘들어 질 수도 있을 듯 합니다.

그렇지요. 후원만으로 먹고 사는게 쉬울리가 없습니다. 그리고 후원도 그렇게 잘 되는 편이 아니고요. 그래도... 응원합니다. 저는 리눅스 민트를 사랑하니까요.

https://blog.linuxmint.com/?p=3662

우분투 18.04.1 기반으로 만들어지고 우분투 18.04와 동일하게 10년간 지원을 받는 리눅스 민트 19.1버전의 베타버전이 릴리즈 되었습니다.

기존 리눅스민트19 버전과 큰 차이는 없지만 ukuu등의 툴 없이 업데이트 매니저를 통해 커널 버전을 선택할 수 있게 되었습니다.

이 외에도 가독성을 높이기 위한 그래픽적 향상이 있다고 합니다. 물론 나머지는 우분투 18.04.1과 동일하니 따로 신경 쓸 이유는 없을 것입니다.

아마도 하모니카 다음 버전은 이 버전을 기반으로 제작하게 될 텐데 이전에 설치 버그를 해결 할 수 있을지는 의문이네요.

현재 전 세계에서 사용되는 OS는 크게 두가지로 나뉩니다. Unix와 그 호환 계열(BSD, Android, macOS, Linux), 그리고 Windows계열 이렇게 입니다.

일반인들은 컴퓨터OS하면 Windows만 떠올리기 때문에 당연히 Windows가 표준일 것이라고 생각하지만 현실을 보면 Unix계열의 점유율이 엄청납니다. 현재 인터넷의 근간을 이루는 서버들은 대부분 Linux를 기반으로 하고 있고 상당부분은 BSD나 Sparc 계열의 Unix입니다. Windows서버의 점유율은 그렇게 높지 않지요.

그리고 클라이언트쪽도 사정이 만만치 않아서 Android나 iOS를 기반으로 한 모바일 계열이 거의 점령한 라서 Unix계열은 거의 전세계IT시장에 상당부분을 가지고 있다고 봐야합니다.

그렇다고 Unix만 신경 쓸 수는 없는 것이 Windows가 PC 데스크탑에서 대부분이고 최종 사용자들이 이것을 쓰니 이쪽도 신경을 써야합니다. 심지어 게임기조차도 Xbox는 Windows기반이지만 PS4는 BSD를 기반으로 합니다.

이러다보니 Windows를 쓰는 사람도 Unix계열을 신경써야하고 Unix계열을 쓰는 사람도 Windows를 신경써야합니다.

하지만 이 둘은 시작이 달랐던 관계로 난감한 일이 자주 벌어지곤 합니다.

가끔 txt파일을 Windows의 메모장으로 열면 중간중간�로 도배되는 경우가 있었습니다. 원인은 텍스트파일에서 문장의 끝을 의미하는 코드가 Windows와 Unix가 달라서 벌어진 일입니다.

그 이유는 줄 바꿈코드가 당시에는 딱히 표준이 정해지지 않아서 CR, LF 라는 두가지가 혼용된 상태였고 리눅스나 Unix계열은 LF(\n)를 매킨토시(macOS9이하를 말함)는 CR(\r)을 Windows는 이 둘을 합친 CRLF(\r\n)을 사용했기 때문입니다.

이 와중에 메모장은 엄청 간단하게 만들어진 프로그램이었기 때문에 기존 DOS시절부터 내려오던 파일방식만을 지원했고 CRLF코드가 아니면 줄바꿈코드가 아닌 다른 코드로 인식했기 때문에 알 수 없다는 의미의 �로 처리되거나 줄바꿈이 무시되어 버린 것입니다.

이 문제는 Windows10 RS4 (1803)에서 해결이 되었고 지금은 Unix방식의 텍스트도 메모장에서 잘 읽어들이고 있습니다.

참고는 https://blogs.msdn.microsoft.com/commandline/2018/05/08/extended-eol-in-notepad/

이게 뉴스로 다뤄질 정도로 정말 오래된 문제라는 것을 아실 필요가 있습니다.

그래서 텍스트 프로그램을 짤 때 Unix방식인지 Windows방식인지 확인 하는 절차를 밟거나 LF든 CR이든 나오면 그냥 줄바꿈을 한다던가 하는 각종 코드들이 만들어지게 되었고 저장할 때 CRLF를 LF로 갈아버린다거나 하는 기능들이 추가되었습니다.

이 문제는 여전해서 Python같은 인터프린터 언어에서는 CRLF와 LF를 둘 다 읽어들여서 처리하는 코드가 들어있고 각종 개발 도구에서는 LF만을 허용하는 등 해당 문제에 대해 대처하고 있습니다. (사실 대다수 개발 도구는 Unix계열쪽을 선호합니다. \n만 쓰기 때문에 편하거든요.)

이외에도 파일 접근시 쓰는 \과 /의 문제도 있습니다.

Windows계열은 C:\Program files\blah blah라고 처리하지만

Unix계열은 /home/moordev/blah blah 라고 처라합니다.

 폴더 구분 기호가 다른 것입니다. 그런데 파일 처리하는 프로그램에서는 절대경로로 처리하려면 \혹은 /을 적어줘야하는 문제가 발생합니다. 그런데 그렇게 만들면 어느 한쪽OS에서만 동작을 하는 문제가 생기게 됩니다. 그래서 귀찮게도 OS구분을 하는 코드가 또 들어가야 합니다. \를 쓸 것이냐 /를 쓸 것이냐룰 두고 함수를 따로 만들어 넣는 것입니다. (그래서 개발자들은 같은 경로에 파일이 있는 것을 선호하는 것일지도 모릅니다.)

오픈소스 프로그램은 그래도 신경을 써서 만들기 때문에 해당 함수를 넣어서라도 OS처리를 하려고 하는 경향이 있습니다. 개발자 입장에서는 다중OS를 위해 귀찮지만 넣는 셈입니다.

아마도 이 문제는 너무 오랫동안 내려온 문제라서 해결이 되는 않을 것 같습니다. 역으로 너무 오랫동안 내려왔기에 사람들이 미처 신경을 못 쓸 지경이 되었습니다. 이 문제가 해결되려면 OS가 어느 한쪽으로 통일 되었을 때일텐데 그 날은 너무 멀게 느껴지는군요.

리눅스 데스크탑의 사용자들은 대부분 가장 빠르게 최신 기술을 써보는 것을 선호합니다. 특히 핫하다는 각종 기술들은 거의 빼놓지 않고 사용하게 됩니다.

하지만 다들 알다시피 최신판이라는 것은 그만큼 안정성 문제가 뒤따르게 됩니다. 그렇기에 최대한의 안정성을 추구하는 데비안은 데스크탑에서 기피되는 배포판이기도 합니다. (사실 데비안 데스크탑도 많이 사용됩니다. unstable이나 testing을 쓴다는 점을 제외하고 말이지요.)

멀리 갈것도 없이 빠르게 변하는 시대의 흐름속에서 각종 IT기사는 새로운 기술에대해 기사를 쏟고 있고 리눅스 사용자들은 윈도우사용자와 다르게 새로운 기술을 써보고자 노력을 합니다.

저 같은 경우에는 리눅스에서 DirectX9가속을 시도하는 Gallium-Nine이나 DirectX11을 Vulkan으로 바꿔주는 DXVK등에 관심이 많았습니다. 문제는 이 기술들이 구현은 되었으나 안정성이 아직 검증이 안 되었다는 거였습니다.

최근에는 Valve에서 Steam용 리눅스에서 Wine을 직접 사용해서 DirectX게임을 돌리는 Proton이란 것을 공개했습니다.

https://github.com/ValveSoftware/Proton

https://itsfoss.com/steam-play-proton/

암튼 스팀에서 윈도우 게임을 굴릴 수 있게 시작되었다는 FOSS의 기사

알고보니 dxvk와 wine을 조합해서 기존 리눅스용 steam에 돌아갈 수 있게 한 것이었습니다. 하지만 기존의 Steam과의 호환성 문제가 해결 되었고 (특히 스팀 메신저를 쓸 수 있다는 것이 컸습니다.) 아직 극히 일부지만 리눅스용을 개발하지 않는 다른 게임도 돌아갈 수 있다는 희망을 얻었습니다.

그리고 이러한 기술은 최신의 우분투를 이용하는 것을 요구했습니다. 거기에 그냥도 아니고 Padoka PPA의 불안정 드라이버를 요구했습니다.

https://launchpad.net/~paulo-miguel-dias/+archive/ubuntu/mesa

심지어 Padoka PPA는 우분투18.04 Bionic Beaver만을 지원하고 있다.

물론 Vulkan지원때문에 그런 것이겠지만 이것은 좀 특이한 행보입니다.

최신의 우분투를 요구하는 것은 그럴 수 있다고 보통 생각합니다. 그도 그럴 것이 우분투18.04도 나온지 4개월이 지나서 안정화가 되었거든요. 하지만 PPA까지 요구한다라...

사실 Padoka PPA는 저도 애용하는 곳입니다. 심지어 Paypal로 후원도 자주 하는 편입니다. 이렇게 최신기술을 적용해서 배포하는 곳이 별로 없거든요. 하지만 역시 안정성 문제가 여전히 따라오고 있고 git에서 빌드하고 바로 가져오기 때문에 생각지도 못한 문제가 터지기도 합니다.

그래서인지 현재 Proton을 사용하고자 하는 사람은 생각보다 적다고 합니다. (애초에 스팀의 베타테스트를 신청해야 하는 것도 있지만요.)

사실 우분투가 LTS버전을 내놓는 것도 이러한 이유가 큰데 최신판 = 언제 터질지 모르는 폭탄 이라는 공식이 존재하기 때문입니다.

기업같은 경우에는 최근 딥러닝용으로 우분투를 사용하는 경우가 늘었는데 우분투 16.04나 우분투 14.04에 눌러 앉은 경우가 많습니다. 첫번째 이유는 그냥 업그레이드가 귀찮아서지만 기업입장에서 하는 말로는 다른 버전에서는 지금 동작하는 것을 보장할 수 없기 때문이라고 합니다. 틀린말은 아닙니다. 하지만 소스컴파일이 되기만 한다면 어떤 버전에서든지 동작 가능한게 오픈소스 프로그램들입니다. 컴파일이 안 된다면 당연히 되는 방법이 나중에라도 나옵니다. 여기서 보통 문제를 일으키는 것은 바이너리인 Nvidia의 프로그램들 뿐이지요.

하여간 리눅스쪽은 얘네가 은근히 문제다. (기억합시다. 토발즈형님의 법규를)

그렇다면 과연 우리는 어떤 버전이 제일 좋은 것일까요?

일단 우리는 윈도우 업데이트를 포함해서 업데이트에 질린 사람들의 이야기를 좀 들어봐야 할 것 같습니다.

사실 너무 구버전은 구닥다리 기술이기에 별로 좋지 않습니다. 2018년 현재 WindowsXP를 사용하는 곳은 구닥다리로 취급되고 있지요. 리눅스도 비슷합니다. 만약 지금 현재 우분투 10.04를 고수하고 있다면(그런 곳은 없겠지만) 진짜 구닥다리가 맞습니다. 하지만 필요에 따라서는 구닥다리가 필요할 수도 있습니다.

그렇다고 너무 최신버전은 역시 안정성 문제가 따라옵니다. 우분투18.04도 나오자마자 데이바이패치가 나왔을 정도로 안정성문제가 나왔습니다. (그래서 8월이 되도록 16.04에 눌러 앉은 사람도 많습니다.) 엄밀히 말하면 우분투18.04에 들어간 버전도 사실 데비안 소스의 1~2월 버전이라고 해도 다른 것이 없는데 안정성문제는 끝나지 않았었지요.

그래서 보통 사람들은 그 중간에서 적당히 찾습니다.

그게 무엇이냐고요???

음...

우분투 계열과 함께 만자로가 비슷합니다.

Arch는 좀 극단적으로 업데이트가 이루어지고 Debian은 극단적으로 업데이트가 뜸합니다. 그렇기에 그 중간인 우분투와 만자로가 인기가 있는 것입니다.

생각보다 간단하죠?

여기서 만자로보다 우분투가 좀 더 보수적이라고 보고 있습니다. 여기서 좀더 최신 기술을 원한다면 PPA 혹은 AUR을 쓰거나 Unstable한 컴파일을 이용하면 되는 겁니다. 제 생각에는 이것이 제일 무난하다고 생각합니다. 

만약 기업에서 요구하거나 기존 바이너리를 써야만 하는 상황이라면? 그렇다면 Docker같은 가상화 솔루션을 이용하면 되지요. 레드햇이나 우분투는 거의 모든 버전의 이미지가 준비되어있으니 Docker를 쓰면 됩니다.

그렇기에 안정화가 보장된 최신판+소스컴파일 혹은 docker 솔루션 이렇게 이용하면 안정성과 최신기술 두마리 토끼를 모두 잡을 수 있지 않을까요?

생각보다 블로그 활동을 안 한지가 오래되었습니다.

이렇게 버려두면 안 되는데...

아무튼 오늘은 리눅스의 하드웨어에 대한 이야기를 해볼까 합니다.

사실 하드웨어는 말 그대로 굴리기 위한 물건들입니다.

하지만 하드웨어를 굴리기 위해서는 드라이버라는 소프트웨어가 필수적입니다. 여기서 리눅스는 대부분 하드웨어지원 문제로 선택폭이 좁아지게 됩니다.

사실 작은 업체의 작은 물건의 경우 대부분 윈도우 드라이버만 지원을 합니다. 아니, 윈도우 드라이버도 정상적인 물건으로 제공한다면 참 다행인데 그나마도 문제가 많은 편입니다. 아무리 작은 물건이라고 해도 칩셋까지 자체적으로 만드는 경우는 별로 없는데 가끔 칩셋도 자체제작하는 업체가 있곤 합니다. 주로 대만 등지에요.

반대로 칩셋이 여기저기에서 자주 쓰이고 많은 업체에서 쓰이는 것이라면 리눅스에서의 지원은 굉장히 활발합니다. 대표적인 것이 리얼텍에서 제조되는 칩셋군인데 리눅스 지원이 참 뭐같기로 유명하지만 어찌된 영문인지 하드웨어 지원폭이 넓은 업체가 리얼텍이기도 합니다. 왜냐하면 사용자층이 높다보니 피드백이 잘 이뤄지거든요.

그래서 이런저런 것을 생각했을 때 리눅스를 굴리기 위해선 어떤 제품을 사는 것이 좋을까? 이런 생각을 할 수 있습니다.

간단하게 말하겠습니다.

그냥 사람들이 제일 많이 사용하는 제품을 사세요. 그것이 HP, Apple 등에서 제조하는 완제품이든 삼성 등의 메모리등의 부품이든 말입니다.

윈도우에서도 많이 사용되는 제품이라면 리눅스의 지원도 잘 될 확률이 높습니다. AMD의 라데온 시리즈는 악명이 높았지만 역시 사용자층이 두터웠기에 현재는 드라이버 안정화가 상당히 되었습니다. 오픈소스쪽에 드라이버 개발을 거의 일임했다고 봐도 과언은 아닙니다. 

그냥 제일 많이 쓰이는 흔한 제품이 가장 리눅스 지원이 잘 되는 제품입니다.

사실 리눅스 프로그램들은 대부분 오픈소스로 구성되어 있습니다. 그래서 마음먹고 포팅하면 다른 OS에도 충분히 이식이 가능합니다. 하지만 Windows의 경우 기존 Windows용 프로그램들이 워낙 강세이기에 여기에 발을 붙이는 것은 어려웠습니다.

하지만 기존 리눅스에서 윈도우로 포팅된 프로그램들이 일종의 대체 프로그램으로 각광받으면서 현재 리눅스용 프로그램들이 윈도우에서 자리를 잡아가고 있습니다. 그 리스트를 조금 확인 해보겠습니다.

1. LibreOffice

리브레 오피스는 사실 OpenOffice시절부터 Windows용이 함께 개발된 프로그램입니다. 사실 리눅스용을 포팅한 것은 아니란 의미입니다.

하지만 리브레 오피스가 그동안 걸어왔던 흔적을 쫓아가면 친리눅스였던 것은 사실입니다. Windows용에는 없었던 OpenGL가속이라던가 리눅스용만 있던 화면 전환 효과 등은 리눅스에 친했던 프로그램이었다는 것을 증명합니다.

하지만 PC사용자의 대부분이 Windows이기에 사용자 수는 Windows용이 더 많습니다. 그런데 그동안 리눅스용에 더 관심을 쏟은 이유는 리눅스용 사용자는 LibreOffice를 더욱 적극적으로 쓰기 때문입니다. 그래서 리브레오피스는 리눅스용으로 인식되어왔습니다.

하지만 리브레오피스6.0부터는 Windows용 기능이 강화되었습니다. 사실 리브레오피스는 MSOffice의 대체가 아닌 새로운 오피스 슈트이길 원하기 때문에 Windows용 지원은 계속 될 예정입니다.

그러니까 Windows용의 부실한 기능이 이제 MSOffice 이상으로 강화될 것이란 이야기입니다.

2. Kdenlive

Kdenlive는 동영상편집도구로 애플의 FinalCut에 비견되는 프로그램입니다. 굉장히 강력한 기능을 쓰고 있습니다.  사실 Windows에서 자주 쓰이는 Adobe의 Premiere와는 목적은 같지만 성향이 다릅니다. (Adobe에 비견되는 건 Cinerella라는 것이 있습니다.)

사실 KDE프로그램은 강력하기로 유명합니다. Konqurer부터 Kate, Amarok 등 KDE특유의 조합하고 떼어서 쓰는 방식은 기존 Windows의 OLE와 닮아있습니다. 하지만 그덕에 KDE프로그램들이 다른 OS로 이식되는 것이 어려웠습니다. 왜냐하면 KDE라는 환경하에서 실행되도록 만들어졌다보니  KDE가 실행되기 어려운 다른 OS는 구동이 어려웠으니까요.

하지만 Kdenlive는 이제 Windows용으로 포팅되어 지금 베타버전을 배포하고 있습니다.

Kdenlive는 기타 간단한 프로그램과 달리 실제 스튜디오에서 쓰일정도로 본격적인 편집이 가능합니다. 그런 프로그램이 무료로 Windows에서 사용이 가능해졌습니다. 아직은 불안정한 면이 많지만 머지않아 자리를 잡을 가능성이 매우 높을 것으로 보고있습니다.

3. Gimp

Windows용이 나온지는 좀 오래되었습니다.

하지만 당시 Windows용이 나오자마자 시장을 뒤집어 엎은 것으로 유명한 Gimp입니다.

이건 자그마치 PhotoShop에 비견됩니다. 사실 Windows98시절부터 은근히 사람들이 Windows용을 기대했을 정도로 강력했던 그래픽 에디터입니다.

그리고 2000년대에 기어코 Windows용으로 포팅이 완료되었습니다. 지금은 PhotoShop을 대체해서 사용이 가능할 정도로 강력한 도구 취급받고 있습니다. 사실 Gimp를 제외하고 무료로 이 정도 기능을 제공하는 프로그램은...없습니다.

하지만 리눅스/유닉스용으로 만들어진 것이다보니 단점이 있는데 Windows용은 많이 느립니다. Windows의 GDI가 아닌 포팅된 GTK를 사용하다보니 벌어지는 일입니다. 이건 Wine으로 윈도우프로그램을 리눅스에서 구동하기는 것과 비슷하다고 봐야겠지요.

4. LMMS

프로툴즈, 큐베이스 등의 작곡 프로그램을 대체하는 LMMS입니다.

사실 음악 한다는 사람들은 대부분 프로툴즈나 큐베이스를 쓰는데(Adobe의 프로그램은...무시합시다.) LMMS는 이 보단 조금 기능이 떨어질지언정 꿀릴것이 없는 성능을 자랑합니다.

VFX를 자체적으로 지원하고 꽤 괜찮은 기본 샘플링도 제공합니다. 물론 이 모든것은 무료입니다. LMMS란 이름이 사실 Linux Multi Media Studio의 약자인데 지금은 Windows용도 나옵니다. 그래서 지금은 그냥 LMMS로 부릅니다.

일선에서 적극적으로 활용하는 프로그램으로 이미 시장에서 인정받은 프로그램입니다. Windows에서 작곡 하는 사람들이 쓴다고 하네요.

5. Audacity

이건 사실 Windows용이 개발단계부터 나왔던 물건입니다. 하지만 역시 그 특징상 리눅스 사용자가 많았던 프로그램입니다.

사운드 에디터인데 골드웨이브나 쿨에디터와 비교가 됩니다. 사실 쿨에디터와 비교하면 초라합니다. 하지만 플러그인이 워낙 많고 Python을 적극적으로 활용하다보니 쿨에디터 못지 않은 기능을 잔뜩 넣을 수 있습니다. 지금은 자체 플러그인 언어도 있습니다.

오픈소스 사운드 에디터하면 10명중 9명은 이걸 추천할 겁니다. 그리고 Windows에서도 무료 사운드 에디터는 Audacity라고 검색이 될 정도입니다. 리눅스에서 인정받은 안정성은 Windows에서도 계속 되고 있습니다.

이러한 리눅스 출신 프로그램(?)은 Windows에서 적극적으로 활용되고 있습니다. 사실 이외에도 많은 프로그램들이 Windows로 포팅되었습니다.

Windows에서도 이러한 프로그램에 침을 흘렸다고 하니 뭐... 이해가 갑니다. 

리눅스 출신들이 Windows에서 쓰이다보면 사용자들이 리눅스로 넘어왔을 때에도 별 거부감이 없이 사용이 가능할 것이라고 믿습니다. 점점 더 침투를 해야겠지요.

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를 서버외의 용도로도 쓸 수 있다는 것을 알아 주셨으면 좋겠습니다.