구글드라이브 많이 사용하고 계실겁니다. 본인이 사용하지 않고 있더라도 안드로이드사용자라면 구글드라이브를 사용하고 있다고 봐야 하거든요.

 

그리고 기본 15GB는 좀 적지만 솔직히 용량대비 가격은 굉장히 착한편입니다. 그리고 제일 중요한건 구글이기에 데이터를 날려먹지는 않을 것이라는 믿음이 있다고 해야겠지요. (대신 구글이기에 내 데이터를 마음대로 보지는 않을까 하는 불안감이 있기는 합니다.)

 

어찌되었건 구글드라이브를 우분투에서 내 디스크처럼 사용하는 방법이 있습니다.

 

문제는 이것도 터미널 작업이 동반된다는 겁니다. 어쩔 수 없을 듯...

 

바로

https://github.com/astrada/google-drive-ocamlfuse

astrada/google-drive-ocamlfuse

FUSE filesystem over Google Drive. Contribute to astrada/google-drive-ocamlfuse development by creating an account on GitHub.

github.com

 

요 프로그램을 이용합니다. 구글드라이브를 fuse로 마운트하는 형태입니다. 일단 마운트가 되니 내 드라이브처럼 사용이 가능하고 웹에서 하나씩 다운로드를 받는 귀찮음도 없습니다.

 

사용방법도 간단합니다.

 

설치는 다음과 같습니다.

우선 터미널을 열고 

 

sudo add-apt-repository ppa:alessandro-strada/ppa
sudo apt update

sudo apt install google-drive-ocamlfuse

 

참 쉽죠?

 

이제 마운트 하는 법입니다. 우선 폴더 하나를 임의로 만듭니다.

저는 ~/GoogleDrive 라고 했습니다.

 

그리고 터미널에서

google-drive-ocamlfuse ~/GoogleDrive

 

이러면 브라우저 하나가 뜨면서 구글 로그인을 요구합니다. 그러면 로그인하고 권한을 허용해주세요. 이제 조금 기다리시면...

 

 

 

Access가 되었다고 뜹니다. 그럼 아까 만들었던 폴더를 파일브라우저(노틸러스, 투나, PCManFM 등등)을 써서 들어가봅시다. 바로 지금까지 구글드라이브에 올린 파일들이 떠있습니다. 이제 파일을 복사하거나 열거나 하면 됩니다. 쉽죠?

,

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

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


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

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


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


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


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


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


thread_submit=true %command%


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

,

우분투 18.04 이후 kdenlive의 업데이트가 뚝 끊겼습니다.

kdenlive측에서는 우분투는 appimage로 패킹된 버전을 쓰라고 하더군요. 어쩐지 우분투 저장소에 있던 버전이 낮다 싶었습니다.


kdenlive의 우분투 계열은 Appimage로 된 버전을 다운로드 받아서 쓰는 것을 추천한다.

아마도 QT와의 호환문제 및 테마 문제로 인해서 (kde 관련 패키지가 어마어마하게 따라옴)이러한 Appimage 버전을 추천한 것 같습니다.


그러나 이 Appimage버전은 한글 입력이 안 된다는 겁니다!!!

그동안 저는 노가다로 복사 부여넣기를 했는데 원인이 알고보니 여기 있더군요.


https://github.com/qTox/qTox/issues/5320


전혀 다른 프로그램이지만 힌트를 여기서 얻었습니다. 일부 Appimage버전의 경우 libfcitxplatforminputcontextplugin.so 파일이 누락되어서 fcitx 사용자의 경우 한글 입력이 되지 않는 현상이 있다는 것입니다.


해당 라이브러리를 정해진 위치에서 찾아다 넣어만 주면 되는 겁니다.


방법은 Appimage파일을 열고 해당 파일을 찾아서 넣은 다음 다시 패키징을 하면 됩니다.


푸는 것은 kdenlive의 appimage파일만 있으면 되고 다시 묶는 것은 appimagetool만 있으면 됩니다.


https://github.com/AppImage/AppImageKit/releases

여기서 appimagetool의 Appimage파일을 다운로드 받으세요. 요즘은 보통 64비트니까 x86_64버전을 다운로드 받으면 됩니다.

32비트라면 i686을 다운로드 받으면 됩니다.


그리고 아까 다운로드 받은 appimagetool과 kdenlive Appimage파일을 같은 곳에 두고 둘 다 실행 권한을 줍시다. 속성에 들어가서 프로그램으로 실행 허용을 주면 됩니다.


자 이제 Appimage파일들이 있는 곳에서 터미널을 열고 다음과 같이 명령을 줍시다.


./kdenlive-18.08.2-x86_64.AppImage --appimage-extract

이러면 squashfs-root라는 폴더가 생기면서 kdenlive의 Appimage 파일의 압축이 풀리기 시작합니다. 


명령어 한번에 압축이 풀린다.

이 안을 들여다보면 우리가 사용하는 시스템의 루트와 똑같다는 것을 알 수 있습니다.

만약 정상적으로 fcitx환경이 설치된 시스템이라면


/usr/lib/x86_64-linux-gnu/qt5/plugins/platforminputcontexts
여기에 libfcitxplatforminputcontextplugin.so 파일이 있을 것입니다. 만약 없다면 우분투 기준 fcitx-frontend-qt5 패키지를 설치하시면 됩니다.


이 파일을 복사해서 squashfs-root내의 같은 위치에 넣어주면 되는 것입니다.

Applimage들 있는 곳/squashfs-root/usr/lib/qt5/plugins/platforminputcontexts

이곳에 들어가면 파일이 하나 부족한 것을 알 수 있습니다. ibus용만 들어있지요. 하지만 ibus는 제가 별로라서 안 씁니다.



여기에는 파일이 하나 부족하다



여기에 libfcitxplatforminputcontextplugin.so 파일을 복사해서 넣습니다.


그리고 다시 Appimage를 만들면 되는 겁니다.


아까 Appimage가 있던 터미널에서

./appimagetool-x86_64.AppImage squashfs-root

이렇게 명령을 내리면...



Appimage 파일을 만들기 시작합니다.


이제 이것을 실행해보면...

kdenlive에서 한글 입력이 됩니다!!!!


그러니까 방법은 하나입니다. 누락된 해당 파일을 넣어달라고 하거나 yml파일을 수정해달라고 넣거나... KDE팀에게 요청을 해야겠습니다.


일단 그동안 임시로 제가 수정한 Appimage버전을 사용해주세요.


https://drive.google.com/file/d/1NVgcCq0sYQHzoOoSE6qALB44NQcuGIBi/view?usp=sharing


Appimage로 된 것이니 그냥 다운로드 받은 다음 실행 권한을 주고 실행하면 됩니다.

,

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초만에 실행이 되면서 편하게 사용이 가능해졌다고 하시더군요.


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


#!/usr/bin/env python3
import subprocess
import os
import signal
import gi
gi.require_version('Gtk', '3.0')
gi.require_version('AppIndicator3', '0.1')
from gi.repository import Gtk, AppIndicator3
import time

app = "firefox"
winsdir = os.path.join(os.environ["HOME"], ".config/hidden_windows")

try:
    os.mkdir(winsdir)
except FileExistsError:
    pass

def checkruns(app):
    try:
        return subprocess.check_output(["pgrep", app]).decode("utf-8").strip()
    except subprocess.CalledProcessError:
        for w in os.listdir(winsdir):
            if w.startswith(app):
                os.remove(os.path.join(winsdir, w))

def get_currentwins(pid):
    wins = subprocess.check_output(["wmctrl", "-lp"]).decode("utf-8").splitlines()
    return [l.split()[0] for l in wins if pid in l]

def hide_currentwins(matches):
    # open(os.path.join(winsdir, "windowlist"), "wt").write("\n".join(matches))
    for w in matches:
        open(os.path.join(winsdir, app+"_"+w), "wt")
        subprocess.Popen(["xdotool", "windowunmap", w])

def run_app(app):
    subprocess.Popen(app)
    while True:
        time.sleep(1)
        pid = checkruns(app)
        matches = get_currentwins(pid) if pid else None
        if matches:
            hide_currentwins(matches)
            break

def restore_wins():
    for w in [w for w in os.listdir(winsdir) if w.startswith(app)]:
        wid = w.split("_")[-1]
        subprocess.Popen(["xdotool", "windowmap", wid])
        os.remove(os.path.join(winsdir, w))

def toggle_app(*args):
    pid = checkruns(app)
    if pid:
        matches = get_currentwins(pid)
        if matches:
            hide_currentwins(matches)
        else:
            restore_wins()
    else:
        subprocess.Popen(app)

run_app(app)

class Indicator():
    def __init__(self):
        self.app = 'toggle_app'
        self.indicator = AppIndicator3.Indicator.new(
            self.app, app,
            AppIndicator3.IndicatorCategory.OTHER)
        self.indicator.set_status(AppIndicator3.IndicatorStatus.ACTIVE)       
        self.indicator.set_menu(self.create_menu())

    def create_menu(self):
        self.menu = Gtk.Menu()
        item_toggle = Gtk.MenuItem('Toggle '+app)
        item_toggle.connect("activate", toggle_app)
        self.menu.append(item_toggle)
        sep1 = Gtk.SeparatorMenuItem()
        self.menu.append(sep1)
        item_quit = Gtk.MenuItem('Quit')
        item_quit.connect('activate', self.stop)
        self.menu.append(item_quit)
        self.menu.show_all()
        return self.menu

    def stop(self, source):
        Gtk.main_quit()

Indicator()
signal.signal(signal.SIGINT, signal.SIG_DFL)
Gtk.main()





우선 이 방식은 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버전의 베타버전이 나오면 일단 써보면서 이런저런 것을 해야겠지요.

,

정확한 이유는 알 수 없으나 일부 사람들에 한해서 우분투 업데이트를 시도 하던 중에 dpkg(설치 프로세스)가 랜덤하게 튕기는 증상이 있었습니다.


지금은 다시 정상화 된 것처럼 보이는데 어떻게 될지는 아직 저도 확신을 할 수 없습니다.


아마도 제 예상에는 우분투 18.04 업그레이드를 위해 과도한 업데이트 요청이 쏟아지면서 각 업데이트 미러 서버 동기화에 문제가 생긴것이 아닐까 싶습니다.


웃긴것은 업데이트가 알 수 없는 오류로 중단 된 이후 다시 업데이트를 시도(apt upgrade)하면 또 업그레이드가 정상적으로 된다는 것입니다.


아마도 우분투 출시 초기의 혼란으로 보이므로 만약 패키지 설치 중 오류가 발생하신다면 차분하게 다시 시도를 해보세요. 혹은 상대적으로 넉넉한 용량을 확보한 하루카상 서버(부경대) ftp.harukasan.org 를 이용하시면 문제가 해결될 가능성이 높습니다.


단, 한번 잠깐 오류가 나는 것이 아닌 만약 패키지의 지속적인 설치 오류가 난다면 그것은 문제가 있는 것이니 꼭 버그리포트를 해주시기 바랍니다.

,

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


우분투 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를 다운그레이드 하는 것도 방법입니다.


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

,

음... 이건 뭐라고 해야하나..

아무튼 대단한 게임이 있습니다. 게다가 무료지요.


뭐라고 해야하지...?


뭐... 자세한 것은 그렇다고 치고 일단 한국어화 패치 사이트는 여기입니다.


https://sites.google.com/view/dokidokikor


여기에 게임의 모든 것을 설명한...것은 아니고 아무튼 잘 번역이 되어있습니다.


이 게임은...일단 미소녀 연예 시뮬레이터의 일종...이라고 하는데 일단 일종이라는 표현을 빌려서... 에휴.. 모르겠다. 아무튼 아는 사람은 다 알테니 게임에 대한 설명은 넘어가겠습니다.


일단 저는 내용 스포일러를 다 당했기 때문에 그렇다 치겠습니다.


이 게임은 지원 OS가 Windows, Mac, Linux입니다.


스팀판이 있다고 하니까 따로 구하기 귀찮아서 스팀에서 설치하려고 하니...


리눅스 지원이 안된다고 나오네요? 리눅스 지원된다고 알고 있었는데 이유가 뭔지 몰라서 공식 홈페이지에 가봤습니다.


https://teamsalvato.itch.io/ddlc



여깁니다. 어차피 무료이니 여기서 다운로드 버튼을 눌러보면 리눅스, 맥, 윈도버전을 다운로드 받을 수 있게 해놓았겠지요.


하하... 게임이 마음에 들면 기부해 달라고 하네요. 네 마음에 드신다면 여기서 필요한 만큼 금액을 적어서 Paypal이나 기타 방법으로 기부를 하시면 됩니다. 일단 저는... 무료로 해보기 위해서 "No, Thanks. Just take me Download." 를 위치고 다운로드를 하기로 했습니다. 그런데 10달러정도는 기부할 만한 게임입니다. 여러가지 의미로 말이지요...


펭귄그림이 윈도용과 함께 있군요. 그러니까 윈도용과 리눅스용은 공용판이었나 봅니다. Windows용을 다운로드 받으면 되겠군요.


다운로드 받은 ddlc-win.zip 압축을 풀어주시면...


요렇게 나옵니다. 여기서 DDLC.sh를 실행하면 됩니다.


음.. 실행 잘 되네요. 그럼 한글 패치를 해봅시다.


https://sites.google.com/view/dokidokikor


여기가 한글패치 배포 사이트입니다. 여기서 우린 스팀판이 아닌(스팀판을 굴릴래야 굴릴 수가 없으니...)일반 사용자 버전을 다운로드 받으면 되겠습니다.


스팀판 패치는 안 먹히니 이걸 다운로드 받으시면 됩니다.


그리고 압축파일의 내용을 그대로 설치된 곳에 풀어서 덮으시면 됩니다.

(렌파이 엔진의 일부도 갈아엎은 듯 합니다. 몇 년전에 제가 Long Live The Queen 작업할 때 비슷한 짓을 했었지요. 이후 해당 기능이 이식되면서 패치를 내려버리긴 했습니다.)


이제 다시 실행해 보겠습니다.


... 윈도와 리눅스의 차이를 아십니까?


권한이 날아가 버렸네요!

이런 빌어먹을 작업을 해야한다는 것이 더 슬픕니다. 마이너는 이래서 슬픈 겁니다.


하지만 권한따윈 복구해주면 됩니다.


게임이 설치된 곳에서

sudo chmod +x lib/linux-x86_64/DDLC

sudo chmod +x lib/linux-i686/DDLC


이렇게 해주면 실행 권한이 다시 살아납니다.


터미널에 이런저런 내용이 뜨면서 실행이 됩니다.


굳이 터미널로 실행한 이유는 뭐냐고요?


.... 이 게임을 해보시면 압니다. 한국어로 아래에 뜨는 경고문 보이시죠? 이것하고 묘하게 관련이 깊습니다.

해커는 역시 터미널을 봐야 직성이 풀린다고 해야할까요...?


저기 있는 SyntaxWarning부터 신경쓰이기 시작하면 이 게임을 아주 잘 아시는 겁니다.



그런데 새 게임을 눌러보니 한글 입력이 안 되네요?

그래서 한글입력을 할 수 있게 Tkinter를 이용해서 한글 입력이 되게끔 수정한 패치를 같이 공개합니다.


http://moordev.tistory.com/246

두근두근 문예부! 리눅스용 한글입력 개삽질



마지막으로...


리눅스에서의 너는 어떤지 한번 보자꾸나.

> 터미널을 같이 띄우는 이유는 이런일이 일어나기 때문입니다.(스포일러 약간 함유.게임을 할 것이라면 누르지 마세요. 주의)




,