'linux'에 해당되는 글 30건

Virtualbox는 리눅스 데스크탑을 사용한다면 싫어도 써야하는 물건입니다. 그 이유야 당연히 Windows환경을 요구하는 경우가 은근히 있기 때문이지요. Wine으로 해결이 가능한 부분도 많지만 Windows 시스템 그 자체를 원한다면 어쩔 수 없습니다. 보통 궁극의 해결책이라고 표현하지요.

특히 유용한 기능중 하나가 USB Passthrough 기능입니다. 리눅스를 통하지 않고 바로 USB장치를 가상머신에 연결하게 해서 Windows드라이버만 지원하는 장치를 돌아가게 하거나 직접 Windows에서 작업 가능하도록 짜인 장비를 연결하는데에 이용가능합니다.

2015년에는 VirtualBox에 주로 WindowsXP를 사용했다면 이후 2019년까지는 Windows7이 그리고 2020년 현재에는 주로 Windows10이 가상머신에 이용되고 있습니다. 그런데 USB3.0을 지원하지 않는 WindowsXP는 그렇다 치는데 Windows7에서 USB장치가 인식이 안 되는 경우가 왕왕 있습니다.

우선 확인해주셔야 할 것은 버전에 맞는 Extension Pack을 설치했는가 입니다.

https://www.virtualbox.org/wiki/Downloads

이곳에 가셔서 VirtualBox Extension Pack을 찾아 다운로드 받아주셔야 합니다.

이것을 설치해 주시면 USB장치를 지원이 할 수 있게 됩니다.

그 다음은 리눅스에서의 권한 문제입니다.

리눅스에서 사용자가 VirtualBox사용 권한을 얻어야 하는데 이를 설정하지 않으면 작동하지 않습니다.

그건 다음 링크에서 확인이 가능합니다.

https://moordev.tistory.com/205

그런데도!!! 아직도!!! 인식이 안 된다면!!!!

그렇다면 한번 USB설정을 살펴봅시다.

우선 Windows장치의 설정으로 들어갑니다.

그리고 USB를 보시면 USB 2.0(EHCI) 컨트롤러 혹은 USB 3.0(xHCI)컨트롤러 둘 중 하나가 체크되어 있을 것입니다. 만약 1.1이라면 당장 바꾸세요. 지옥의 속도를 경험하게 됩니다.

여기서 한가지 알 수 있는 것은 USB 1.1에서는 인식이 되는데 2.0이상일 때 인식이 안 되거나 혹은 2.0은 되는데 3.0이 안 되는 경우가 있다는 것입니다.

이 것은 Windows 문제입니다. Chipset Driver나 USB드라이버가 설치되어 있지 않아서 벌어진 일입니다. 

Windows를 설치한 다음 우리는 보통 업데이트를 바로 돌려버리거나 알아서 업데이트를 하는데 이때 장치 드라이버가 자동으로 설치됩니다. 그런데 VirtualBox에서는 장치인식문제로 드라이버가 자동으로 설치되지 않는것입니다.

그렇다면 수동으로 설치하면 된다는 의미겠지요.

https://downloadcenter.intel.com/download/22824/Intel-USB-3-0-eXtensible-Host-Controller-Driver-for-Intel-8-9-100-Series-and-Intel-C220-C610-Chipset-Family

여기 있는 이 드라이버를 설치하거나

https://downloadcenter.intel.com/download/22904/Intel-USB-3-0-eXtensible-Host-Controller-driver-for-S1200V3RP?wapkw=USB

이 드라이버를 설치하면 됩니다.

만약 Windows10환경에서 안 된다면 그냥 Windows Update에서 한번 싸아악 돌리면 해결됩니다!

Unity3D는 매우 훌륭한 게임엔진이고 성공한 게임엔진입니다. 그리고 정말 많은 분야에서 사용중입니다.

그러나 Unity3D로 게임을 개발을 하기 위해선 윈도우나 맥OS환경이 필수 였습니다. 하지만 Unity3D측에서도 실험적으로 리눅스용을 만들고 지원하고 있습니다. 명색이 다용도 엔진이기 때문에 리눅스용 게임도 만들 수 있는데 개발도 리눅스에서 할 수 있게 하기위한 방법인 것입니다.

물론 경쟁자인 Unreal엔진이 비슷한 노선을 취하기 때문인 것도 맞는 것 같습니다.

Unity3D는 버전별로 상이한 방식을 취하기 때문에 여러 버전을 설치하는 것이 당연시 되고 있습니다 .이를 관리하기 위해서 UnityHUB란 것을 만들었고 최근에는 개발 환경을 이것으로 갖추고 있습니다.

https://forum.unity.com/forums/unity-hub.142/

이곳으로 들어가시면 알 게 됩니다.

해당 포럼에 들어가면 UnityHub XXX is available!! 이런 식으로 써 있습니다. 그 글을 클릭 하면..

이렇게 3대 OS용 UnityHub를 다운로드 받을 수 있게 되어있습니다. 여기서 리눅스도 다운로드 받을 수 있게 되어있습니다. 그리고 이를 다운로드 받으면..

Appimage 형태로 다운로드 됩니다. 즉, 리눅스 배포판을 가리지 않고 실행 되는 방식입니다. 속성에서 

그리고 일반적인 프로그램 실행하듯 실행해 주시면 됩니다. 메뉴에 등록할거냐고 물어보는데 저는 그냥 귀찮아서 등록을 안 하는 것을 선호합니다. 그건 알아서 선택하시기 바랍니다.

그리고 계정 로그인을 하고 잠시 기다리시면...

이렇게 엔진 개발환경을 다운로드 받을 수 있습니다. 

심지어 필요한 컴포넌트도 다운로드가 가능합니다. 굉장히 편리하지요. 그러면 Unity3D 개발환경을 구축 할 수 있게 됩니다. 설치 위치는 톱니바퀴 모양을 누른다음 설정에서 건들 수 있습니다. 물론 권한이 있어야 가능하겠지요?

개인적으로 /opt 안에 폴더를 하나 만든 다음 권한을 따로 주는 것을 선호하지만 ~/안에 설치하는 것을 선호하는 사람도 있을 것입니다. 그것은 취향차이라고 합시다.

이제 프로젝트 탭에서 프로젝트를 하나 만들고 실행해 봅시다.

그러면 짜잔!! 이제 리눅스용 unity3D를 설치할 수 있게 되었습니다. 짝짝짝

추가로 만약 에디터 환경이 너무 느리다 싶으면 OpenGL대신 Vulkan을 사용해 볼 수 있습니다. 확실히 Vulkan이 속도가 빠릅니다.

방법은 Edit-Project Settings

한글판의 경우에는 다르게 나올 수 있다. 하지만 보통 이런 툴은 영문판을 쓸 테니 영문으로 설명한다 알아서 따라오자

그 다음에 Player 탭에서 아래로 쭉 찾아서 Rendering을 찾은 다음 Auto Graphic API for Linux에 체크를 해제합니다. 어차피 윈도는 DirectX11로 고정이고 macOS도 Metal로 고정입니다. 리눅스만이 OpenGL과 Vulkan 두가지를 지원합니다.

그리고 나온 창에서 OpenGL Core가 위에 있을 텐데 Vulkan을 OpenGL Core위로 땡겨서 OpenGL보다 Vulkan이 우선되도록 합니다. OpenGL이 위에 있는 이유는 호환성 때문인데 (구형 VGA는 지원이 안 됨) Vulkan이 이러나 저러나 빠르기 때문에 Vulkan을 추천합니다.

이제 리눅스에서도 Unity3D 엔진으로 이용한 게임 개발이 쉬워졌습니다.

참고로 C# 에디터가 필요하다면 개인적으로 VSCode를 설치하시는 것을 추천합니다. MonoDevelop보다 깔끔하더군요. 그리고 VSCode를 cs파일을 열때 기본으로 설정해두면 Unity3D에서 스크립트를 수정할 때 유용합니다.

VSCode를 설치하는 방법은 따로 검색하시는 것을 추천합니다.

Steam의 Proton지원으로 인해 리눅스에서 게임하기가 한결 더 쉬워졌습니다.

2018년 현재 주류 게임개발 라이브러리는 DirectX11입니다. 대부분 게임들이 11버전으로 만들어지고 있지요.

SteamPlay는 이러한 DirectX11버전을 Vulkan으로 변환해서 플레이를 할 수 있도록 도와줍니다.

하지만 역시 기본 바탕은 wine이기에 Wine으로 인한 오류는 그대로 나타납니다. 저 같은 경우에는 Thread관련 오류가 많이 났는데 이를 해결하는 방법을 알려드리고자 합니다.

AMD CPU에 Unity3D엔진에서 특히 오류가 잦았는데 원인은 아직도 알지 못합니다. 보나마나 멀티코어활용 문제겠지요.

방법은 thread_submit옵션을 켜서 각 thread를 넘나들때 GIL처럼 잠그는 기능(?)을 활성화 하는 겁니다. 이때 속도 문제가 발생하지만 그래도 게임이 다운되지는 않습니다.

오류가 나는 게임의 속성으로 들어갑니다.

여기서 시작 옵션 설정을 눌러주시고

thread_submit=true %command%

위와 같이 적어줍니다. 그리고 실행하면 Thread관련 오류를 잡을 수 있게 됩니다.

Linux용 Steam에서 Steam Play(Proton)을 사용해서 이런저런 많은 게임을 구동했습니다. 하지만 Wine도 완벽하지 않고 그것을 기반으로 한 Proton도 완벽하지 않기 때문에 모든 게임이 구동되는 것이 아닙니다. 그래서 Protontricks 같은 각종 트릭을 써서 구동을 하고 있습니다. (https://moordev.tistory.com/284)

하지만 게임 구동이 안 되는 것이 Wine문제일 수도 있고 DXVK 문제일 수도 있습니다. 사실 DXVK이전에 WineD3D로 기존 Direct3D게임을 OpenGL로 구동하는 방법이 있었습니다. 이쪽은 느리긴 하지만 구동 자체는 완벽합니다.

보통 DXVK문제로 Steam Play에서 오류가 나는 경우는 다음과 같습니다.

The Island : In To The Mist란 게임으로 GameMaker2 엔진을 사용했고 DirectX11을 요구합니다. 그런데 저 오류 코드는 VRAM관련 오류인데 제 시스템에서 오류가 날 이유가 없습니다. 이 게임은 VRAM을 512MB만을 요구하거든요. 그러니까 하드웨어 문제가 아니라는 의미입니다. 결론은 Proton의 문제란 것이고 이걸 해결 하는 방법은 간단합니다. DXVK를 써서 Vulkan 모드로 구동하지 않고 WineD3D로 OpenGL모드로 구동하게 하면 됩니다.

Vulkan 드라이버 설치 및 SteamPlay를 활성화 했다는 가정하에 이야기 하겠습니다.

SteamPlay 활성화는 https://moordev.tistory.com/282 이 곳을 참고하세요.

게임 이름의 속성으로 들어갑니다.

"시작 옵션 설정..." 버튼을 누릅니다. 

여기에

PROTON_USE_WINED3D11=1 %command%

라고 적어주시면 됩니다. 뒤에 %command%까지 적어주셔야 합니다.

그리고 플레이 버튼을 누르면...

리눅스에서 문제 없이 구동이 됩니다!

만약 Vulkan이 구동이 안 되는 구형 시스템이라면 이 옵션으로 게임이 돌아가는 경우가 많다고 하니까 참고하세요!

Unity3D 엔진을 활용한 게임에서 나는 이런 오류도 같은 방법으로 해결이 가능합니다.

Firefox나 Chrome은 초기 구동속도가 매우 느립니다. 처음에 메모리에 올려야 하기 때문인데요. HDD를 쓰는 경우 속도가 더더욱 느려서 처음에 속도가 상당히 느려서 상당히 답답함을 느끼시는 분이 많습니다.

제 시스템에서는 Firefox가 약 10초 Chrome은 40초정도의 초기 실행 성능을 지니고 있습니다. 솔직히 10초는 기다릴만하다고 생각했는데 Windows에서 IE나 Edge를 실행해보셨던 분들은 아시겠지만 얘네들은 바로바로 실행되는 모습을 볼 수 있습니다. 이유야 당연하게도 Windows에서는 미리 컴포넌트들이 메모리에 올라가 있기 때문입니다. 그래서 Chrome은 이명이 느긋한 돼지라는 별명을 지니고 있습니다. Firefox는 여우답게 날렵했지만 Chrome과의 렌더링 속도에서 져버린 이후 Chrome과 같이 초기 구동 속도가 느리지만 웹렌더링 속도를 올리는 방식을 사용합니다.

그럼 방법은 뭐가 있느나...

Chrome의 경우 처음 실행 후에는 다시 실행을 해도 금방 실행이 되는 모습을 보입니다. 왜냐하면 모든 창을 다 꺼도 백그라운드에서 숨을 죽이고 있기 때문입니다.

아래 그림과 같이 말입니다.

크롬은 한번 실행 후에 백그라운드에서 대기를 타는 방식을 사용한다.

이렇게 하면 체감 속도가 엄청 향상되는 효과를 얻습니다. 역으로 말하면 다른 브라우저들도 백그라운드에서 미리 실행을 해두면 웹브라우저를 빠르게 실행이 가능하다는 의미가 될 수 있습니다. 요즘에는 메모리관리를 열심히 해주지 않아도 충분히 사용이 가능한 시대이기 때문에 자주 쓰는 프로그램을 미리 실행해두는 것도 나쁜 생각이 아닙니다. Chrome이야 그렇다 치지만 Firefox는 메모리도 적게 먹으니까 백그라운드에 실행해 두었다고 해도 문제될 것은 없습니다.

http://hamonikr.org/board_aMBI05/52629

여기서 바람곰돌님이 초기 브라우저 속도가 너무 느리다면서 나온 이야기입니다. 그래서 제가 인터넷을 검색해서 Firefox를 백그라운드에서 실행하는 방식을 추천했지요.

https://askubuntu.com/questions/853891/how-can-i-make-firefox-run-in-the-background-like-chromium

여기에 나온방식으로 스크립트를 만들고 Firefox를 컴퓨터 실행 후에 백그라운드로 실행하니 4초만에 실행이 되면서 편하게 사용이 가능해졌다고 하시더군요.

그래서 이렇게 된 거 여기에 이 방식을 한국어로 소개하려고 합니다.

우선 이 방식은 Firefox를 wmctrl을 이용해서 보이지 않게 뒤로 실행하는 방식입니다.

따라서 wmctrl과 xdotool이 필요합니다.

sudo apt-get install wmctrl xdotool

그 다음 python3를 이용해서 firefox를 실행한 후 wmctrl에게 프로세스 ID를 넘겨 보이지 않게 하는 것입니다. 뭐... 이건 그냥 쓰시는 분께는 어려우니까 자세한 설명은 하지 않겠습니다.

위의 스크립트를 복사해서 firefox_bg.py 라고 만들어둡시다.

물론 Python3는 당연히 있다고 생각하고 만드는 것입니다.

해당 스크립트는 만들고 싶은 곳에 만들어 두시면 됩니다.

저는 ~/.firefox_bg/ 에다가 만들었습니다.

그리고 시작프로그램에 해당 스크립트를 실행하게끔 등록합시다.

LinuxMint나 우분투에서는 시작프로그램을 설정 창을 통해 설정할 수 있습니다.

여기서 추가버튼을 누르시고

이름은 마음대로 알기 쉬운 것으로 해주시고

명령은

/bin/bash -c "sleep 5 && python3 ~/.firefox_bg/firefox_bg.py"

이렇게 해둡시다.

뒤의 ~/.firefox_bg/firefox_bg.py 는 제가 해당 위치에 스크립트를 만들어 두었기 때문입니다. 여러분들은 여러분들에게 맞는 위치를 지정해주세요.

설명 부분은 비워도 됩니다.

이제 등록이 되면... 한번 시스템을 껐다 켜 봅시다.

Firefox가 크롬처럼 미리 메모리에 올라와 있습니다. 생각보다 메모리 먹는 양은 많지 않습니다.

그리고 한 가지 더 생각해야 할 것이 있는데 의외로 우리는 웹브라우저를 제일 많이 사용한답니다. 그러니까 Firefox를 미리 메모리에 올렸다고 해도 문제될 것이 없습니다. 물론 크롬을 주로 사용하신다고 하면 Chrome을 이런 식으로 실행해두는 것도 방법입니다.

discord 이전에 자주 사용되었던 팀보이스와 스카이프를 대신 할 수 있는 훌륭한 목소리 채팅 프로그램입니다. 음질은 팀보이스보다 훨씬 좋고 딜레이는 스카이프수준입니다. (제일 가까운 서버가 일본에 있어서 이 정도지 더 빠를 수도 있습니다.)

요즘에는 리눅스에서도 게임을 자주 하기 때문에 디스코드를 사용할 일이 많은데 우분투계열에서 Discord를 사용하는 방법을 간단하게 알려드리겠습니다.

다만, 약간 속은 기분이 들지도 몰라요.

https://discordapp.com/download

이쪽으로 접속합시다.

그러면 알아서 OS에 맞춰서 데스크톱앱을 다운로드 할 수 있게 해줍니다. 우분투에서 쉽게 설치가 가능하도록 deb으로 배포하고 있습니다. 물론 Deb이 지원 안 되는 배포판에서도 사용 가능하도록 tar.gz도 배포하고 있습니다.

deb을 다운로드 받으면 그냥 설치가 가능하겠지요. 설마 이것도 못하는 사람은 없을 것이라고 봅니다...

터미널을 사용하는 변태는

sudo dpkg -i discord*.deb

물론 그냥 마우스로 실행해서 설치하는게 제일 빠릅니다.

그리고 실행하면 그냥 별 문제없이 됩니다....

그리고 한번 로그인하라고 브라우저가 실행되는데 그냥 디스코드에 가입하고 로그인하시면 됩니다. 쉬워요.

그러면...

네 끝났습니다. 이제 그냥 쓰시면 됩니다. 나머지는 discord 사용방법만 아시면 됩니다.

그런데 이게 가능한 이유를 알면 황당하실지도 몰라요.

사실 이건 HTML5의 위엄입니다.

자세히 보시면 따로 데스크톱앱을 설치하지 않고도 웹브라우저에서 사용이 가능 한 것을 알 수 있는데 그게 HTML5를 쓰기 때문입니다. 그럼 데스크톱앱은 뭐냐... 그냥 자체 브라우저 만들어서 띄운겁니다. 끝이에요.

제가 속은거 같은 기분이 들지도 모른다고 한 이유가 이겁니다. 하지만 이게 기존 스카이프나 팀보이스보다 더 성능이 좋다는 것...

아무튼 우분투에서 디스코드를 사용 할 수 있습니다. (뭔가 정말 속은 기분이야...)

이제 곧 6월 4일(세계 표준시 기준)에 리눅스 민트 19 Tara의 베타버전이 배포됩니다.

사실 이미 테스트버전이 FTP를 통해 배포중이었습니다. ftp://ftp.heanet.ie/pub/linuxmint.com/testing/

이미 이쪽을 통해 사전 다운로드가 가능했었다.

하지만 공식홈페이지에는 아직 올라오진 않고 있었는데 이번 6월 4일을 기준으로 공식적인 19 Tara의 베타버전이 배포될 예정입니다. 이번 리눅스 민트 19는 기존 16.04기반의 18.x버전과 달리 우분투 최신 버전인 18.04를 기반으로 만들어지고 있습니다. 따라서 우분투 18.04에서 개선된 것이 적용이 될 것입니다. (인텔의 Meltdown 완화 패치 포함) 

큰 기대는 하지 않지만 반대로 실망은 절대로 하지 않는 배포판이기에 초보자 및 본격적인 데스크탑으로 사용하고자 하는 분들에게 많이 추천하는 배포판입니다. 우리나라의 HamoniKR프로젝트(http://hamonikr.org/)도 이것을 기반으로 하고 있고 저도 이걸 기반으로 배포를 많이 했었지요. 

일단 우분투 18.04기반이기에 그동안 우분투 18.04가 쌓은 호환성 문제를 해결하고 이를 따라서 개인 PPA들이 지원하는 각종 프로그램들을 이용이 가능합니다. 18.2에서 18.3으로 넘어갈 때에는 Time Shift기능을 통해서 차별화를 했는데 이번에는 어떤 것을 가져올지 기대되는군요.

Tara버전의 베타버전이 나오면 일단 써보면서 이런저런 것을 해야겠지요.

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

우분투 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는 상당히 안정적인 버전이 될 것임을 예상합니다.

LibreOffice가 어느새 6.0으로 업데이트 되었습니다.

기존 5.0보다 더욱 좋아진 기능으로 무장했고 더욱 호환성을 높혔습니다.

그런데 그에대한 반동으로 상당히 무거워졌습니다. 왠지 MSOffice가 갔던 그 길을 따라가는 것 같아 슬프네요.

하지만 뭐 이걸 어느정도 완화 할 수 는 있습니다. 물론 기본적으로 무거워 진 것은 어쩔 수 없으니 답답하면 버전을 낮추기라도 해야겠지요. (....아니면 이참에 다른 것으로 바꿔야 할지도 모르겠네요.)

일단 LibreOffice의 아무 프로그램이나 실행한 다음

도구-옵션으로 들어갑니다.

그다음 Advanced를 찾아 들어갑니다. 아직 번역이 완벽히 되지 않아서 한글과 영문이 섞여 있습니다.

여기서 Open Expoert Configuration 즉, 전문가 설정을 눌러 들어가도록 합시다.

참고로 여기서 JAVA를 꺼주시면 조금이나마 더 성능이 나아지기도 합니다. 대신 일부 기능을 못 씁니다.

여기서 org.openoffice.Office.Common에서 Cache -> GraphicManager 순으로 열어서 확인합니다.

여기서 캐시크기를 늘려주면 그림이 많은 문서를 작업할 때 캐시를 확보해서 어느정도 버벅임을 줄일 수 있습니다. TotalCacheSize와 ObjectCacheSize를 늘려주세요. 물론 적당히 늘려야 메모리를 절약할 수 있겠죠?

그리고 확인을 누른다음 옵션에서 보기를 누릅니다.

그래픽출력을 확인해보시면 하드웨어가속 사용이 있는데 시스템에 따라 하드웨어가속을 써야 빠른 경우가 있고 하드웨어 가속을 꺼야 빠른 경우가 있습니다. 그건 상황에따라 다릅니다. 그리고 OpenGL렌더링 사용은 왠만하면 체크해두세요. Ignore OpenGL Blacklist는 체크를 해서 쓰다가 렌더링이 깨지면 그냥 OpenGL 사용 자체를 꺼주세요. 일부 GPU에서 렌더링이 깨진다고 합니다.

일단 이렇게만 해도 적당히 돌아는 갑니다. 그런데 아직도 답답하다면 LibreOffice를 다운그레이드 하는 것도 방법입니다.

뭐... 차차 나아지겠지요.

PlayonLinux는 제가 애용하는 프로그램 중 하나입니다.

이것으로 수많은 프로그램을 실행하고 성공이야기를 썼지요. 하지만 언제부터인지 한국어 번역이 중단 되어서 영문과 한국어가 혼재된 상태에 빠져있었습니다.

그렇기에 제가 http://moordev.tistory.com/244 여기서 예시로 언급하기까지 했지요.

그래서 이 참에 그냥 번역을 새로 했습니다. 다만 내용이 너무 방대했던 관계로 처음부터 그냥 한 것은 아니고 구글 번역기와 함께 작업을 했습니다. 요즘 구글 번역기 좋더군요. 가끔 엉망이긴 하지만 가끔 그럴 뿐이고 다른 것은 꽤 괜찮았습니다. (무슨 말인지...)

pol.mo.zip

해당 파일을 다운로드 받아 압축을 풀고 pol.mo를 /usr/share/locale/ko/LC_MESSAGES

폴더에 덮어주시면 PlayonLinux가 일단 가능한 선까지 한국어화가 되어서 보이게 될겁니다.

PlayonLinux팀에다 해당 번역을 보냈는데 소스 트리에 넣어줄지는 잘 모르겠습니다. 언젠가는 해주겠지요 뭐.