'분류 전체보기'에 해당되는 글 400건

이 글은 2014년 1월 5일 원래 제 다음 블로그에서 가져온 글입니다.

Long Live The Queen 프린세스메이커의 패러디 게임이라고 하는데 죽을일이 없는(가끔 가출은 하더만...) 프린세스 메이커와는 다르게 잘못된 선택은 곧 죽음인 살얼음판의 프린세스메이커라고 한다고해서 가격도 싸길래 냉큼 질러보았다.(사실 리눅스 지원인것도 한 몫했다. 리눅스 지원 게임이 그리 많지는 않으니..최근 개인프로젝트로 돌릴까 하는 클라우드게이밍도 스팀이 리눅스를 지원하면 그냥 클라우드 데스크탑에 스팀만 띄워주면 되니까 쉬워진다.)

일단 냉큼 지르고 영어의 압박을 간단히 떨친후(사실 영어로 되어있어서 반대로 게임하기 수월했다.) 뭐가뭔지 몰라(...) 공략을 찾던 중 이 게임이 Ren'Py라는 엔진으로 만들어졌다는 것을 알았다.

 Ren'Py... 이름에 왠지 Py가 들어가는데다가 MacOSX, Linux, Windows를 전부 지원한다? 혹시 이거 Python?하고 스팀설치 폴더에 들어가서 뜯어본결과 Python맞더만...그것도 PyGame이라는 엔진을 비주얼노벨용으로 만든게 Ren'Py고 PyGame이 안드로이드도 지원하기 때문에 Ren'Py도 안드로이드 지원이 가능하다고 되어있었다.

그러나. 이 게임은 스팀에서 판매하기에 안드로이드 지원이 될 턱이 없었고 스크립트 언어인 Python이라면 별 저항없이 안드로이드에 이식이 되지 않을까 하던중 RenPy SDK에서 안드로이드 지원이 가능하다는 것을 찾아내었다.

흐음...이걸 일단 안드로이드에 이식해 보기로 하고 결국 휴일에 삽을 들고 말았다...에라이.

 자 안드로이드 포팅(?)을 위한 준비물을 우선 말해보도록 하겠다. 여기서는 우분투같은 리눅스 환경에서 작업하는 것으로 되어있습니다. Mac이나 Windows는 스팀게임의 경로나 안드로이드폰 연결방법등이 다릅니다.

 http://baekansi.hosting.paran.com/doc/html/android.html

여기에 일단 안드로이드용으로 컴파일 하기위해 어떻게 해야할지 자세히 나와있다.

우선 필요한 것은

1. Ren'Py SDK http://www.renpy.org/latest.html

2. Oracle JDK http://www.oracle.com/technetwork/java/javase/downloads/index.html

3. Python 2.7 이건 뭐...알아서 검색하던가 sudo apt-get install python2.7

4. RAPT(렌파이 안드로이드 패키징 툴)http://www.renpy.org/dl/android/

5. 손을 댈 Ren'Py로 만들어진 게임(여기선 Long Live The Queen 되시겠다. 이건 Steam관련 스크립트가 있긴 하지만...스팀없이도 실행되는 것을 확인)

6. rpatool https://github.com/Shizmob/rpatool  rpa나 rpi등으로 이미지나 음악들이 압축 되어있는 경우 어쩔 수 없이 이 파일들을 풀어 해쳐놓아야 안드로이드에서 실행이 된다. 아니면 다른 방법이 있을 수도 있는데 방법을 잘 모르겠다.(...)

7. 삽질을 위한 안드로이드 기반 기기(에뮬레이터는 비추)

8. adb 안드로이드개발 홈페이지에서 다운로드 받던지 아니면 sudo apt-get install android-tools-adb

*. 당신의 삽질력

일단 되었으면 JDK와 Python을 설치하자.

그리고 Ren'Py SDK를 적당한곳에 압축을 풀고 RAPT를 Ren'Py SDK의 압축 푼곳에다가 같이 압축을 풀어넣자.

압축 풀기가 완료되었다면 renpy.sh를 실행해서 Ren'Py런처가 실행이 잘 되는지 우선 보도록 하자. 되었다면 예시로 같이 들어있는 것도 실행해 보고 이것저것 하다가 일단 종료.

 이 제 스팀에서 Ren'Py게임을 구입하자. 아니면 조금 뒤적거리면 무료로 좋은 게임을 배포하기도 하니 잘 찾아보자. 걔중엔 지하철에서 하기에는 조금 엄한물건도 있기는 하지만....여기서는 아까 말했던 Long Live The Queen(이하 LLQ)을 이용하도록 하자. 그리고 꼭 한번 실행시켜주자. 가끔 스팀이 제대로 다운로드 안 하고 다 됐다고 사기치는 경우가 있어서 그런것이니  한번은 꼭 실행시켜보도록 하자.

실행이 확인 되었으면 ~/.local/share/Steam/SteamApps/common 로가면 당신이 그동안 스팀에다가 쏟아부은 결과물들이 들어가 앉아 있다. 여기서 Long Live The Queen이란 이름의 폴더째로 일단 복사하자.

 복사한 폴더는 위의 Ren'Py SDK와 RAPT의 압축을 풀어넣은 곳에다가 붙여넣기 하면 된다. 다시 한번 renpy.sh를 실행해보자. LongLifeTheQueen이 보이는가? 오른쪽에 Android라고 보이는가? 여기에 보면 Emulation으로 실행을 해볼 수 있다!!!! 그.러.나. 여기서 실행하면 당연하다는 듯이 에러난다. 이 에러를 잡는 것이 바로 이 삽질의 핵심이다.

삽질의 처음은 로그를 뜯어보는 것이다. 로그를 한번보자. glpatch.rpy가 에러가 났다고 나온다. 하지만 게임폴더를 아무리 뒤져도 rpy파일은 보이지 않는다. 사실 파이썬을 써보면 알겠지만 속도를 위해 한번 바이트코드로 컴파일하게 되는데 렌파이도 비슷한 원리로 스크립트를 컴파일 해 놓은 것이다. 즉 로그에서 rpy라고 나오는 파일이 사실 rpyc를 말하는 것으로 생각해도 좋다.
 

 암튼 glpatch라는 놈이 문제라고 되어있는데 이미 컴파일되어있는 스크립트를 어떻게 해볼 수는 없고 한번 제거해보도록 하자.즉 삭제! 그리고 빈파일을 하나 만들어서 glpatch.rpy라고 하나 만들어 놓자. 빈 파일이기 때문에 아무런 내용은 없지만 그렇다고 파일이 없으면 그건 그것대로 또 에러가 난다. 말그대로 patch라고 되어있는 걸로 봐서 OpenGL관련 문제를 해결한 패치로 보인다. 그러나 안드로이드에서는 저게 도리어 문제를 일으키니 패치를 없애도록 하자. 그리고 한번 게임을 실행해보면 glpatch.rpyc가 생성되어있는 것을 알 수 있다. rpy가 빈파일이므로 rpyc도 빈내용으로 만들어진 바이트코드가 된다. 이걸로 한 가지 알 수 있는 것은 저 패치는 PC에서만 통하는 것으로 보인다는 것. 아마 Nvidia나 ATI드라이버 호환내용이 아니었을까?

아까처럼 PC에서 renpy.sh를 실행하고 Android - Emulation - Phone 혹은 Tablet 를 실행해보자. 이번에는 타이틀 화면이 뜬다? 참고로 Translation.rpy를 작성한뒤 game폴더에 넣어주고 Translation.rpy에 폰트를 지정한다음 해당 폰트를 Game폴더에 같이 넣어주면 폰트도 맘대로 바꿀 수 있게 된다. 다만 은폰트나 나눔 폰트를 이용하는 것을 권한다. 맑은 고딕도 예쁘지만 이건 MS가 저작권을 지니고 있어서...Translation.rpy작성법은 http://www.renpy.org/wiki/Ren%27Py_%EC%97%90%EC%84%9C_%ED%95%9C%EA%B8%80_%EC%84%A4%EC%A0%95%EC%97%90_%EB%94%B0%EB%A5%B8_%EC%95%88%EB%82%B4

여기를 참조하시길

이제 안드로이드용으로 컴파일을 해보자. 해보기에 앞서서 터미널 사용법을 알고 있으리라 믿는다.

 renpy가 설치된 곳으로 가서 (RAPT의 압축을 푼 곳으로 가서)

./android.py installsdk

라고 치면 이 녀석이 안드로이드 SDK를 다운로드 받으면서 이것저것 물어보게 된다. 그냥 yes 혹은 no라고 대답만 하면 알아서 잘 해주니 그냥 시키는대로 하자.

그다음

./android.py configure LongLiveTheQueen

이라 치면 configure 뒤에 붙은 게임의 안드로이드 설정을 하게 된다. 역시 묻는말에 꼬박꼬박 대답하면 된다. 개인적으로는 2.2기반보다 4.0기반으로 만드는 것을 추천한다. 3.0은 그냥 버리는 거다.

이제 설정이 끝났다면 드디어 APK빌드를 해보게 된다. 이에 앞서 안드로이드 폰을 PC에 연결하고 ADB설정을 하고 디버그모드를 허용까지 해주어야 편하다. ADB설정은 이 블로그 어딘가에 잘 써있으니 참고.

일단 안드로이드기기를 PC에 연결하고

./android.py build LongLiveTheQueen release install

이렇게 하면 안드로이드용으로 빌드도 하고 안드로이드기기에 알아서 설치까지 다 해준다.

이제 실행해보기전에

./android.py logcat

을 실행하고 기기에서 게임을 실행해보자. (Ren'Py기본 아이콘에 기본로딩화면이 뜬다. 이는 RAPT루트/res/drawable을 교체함으로써 바꿀 수 있다. 이건 그냥 참고사항

아마도 혹은 역시나 에러를 내뿜어 주실것이다.

 steam.rpy

결국 스팀이 일을 내주셨다. 아까처럼 steam.rpyc를 삭제하고 빈파일로 steam.rpy파일을 하나 만든 후에 게임을 한번 실행하고 다시 APK를 만들어주자.

그리고 bytecode.rpyb파일은 그때그때마다 삭제해놓길 바란다. 게임실행속도를 올리기위한 방법중 하나지만 APK의 용량증가의 원인중 하나이므로...

이제는 안드로이드기기에서 타이틀화면을 봐야 정상인데....

 안된다. 그럼 아까처럼 logcat을 한번 보자.

  왠 아이콘 이미지를 못 찾는다고 뜬다.(icon-big.png)ignore 버튼을 누르니 이번엔 배경이미지를 못찾는다고 하고 배경음악도 못찾는다고 하고..

이 파일들 아까 Game폴더에 없었는데?

 사실 이것의 경우는 안드로이드용 렌파이의 문제일것으로 보인다. 게임 개발자나 회사에서 감추고픈(?) 이미지나 음악들이 떠돌아다니는 것을 싫어하기에 Ren'Py에서는 rpa라는 파일로 압축+암호화를 하는데 이게 안드로이드 내에서 정상적으로 복호화가 진행이 되지 않은 것이다. 잘 뒤져보면 llq.rpa란 파일이 보인다. 아마 못찾는다고 뜬 파일들은 이 안에 다 있을 것이다. 그럼 이걸 풀어서 game폴더에 흩뜨려 놓으면 정상적으로 실행이 될 것이다.

그럼 무엇으로 복호화를 할까? 아주 간단하게도 rpatool을 이용하면 된다. 이 것도 하나의 파이썬 스크립트로 되어있는데 그냥 game폴더에 넣어주자. 그리고 cd명령으로 game폴더까지 들어간다음

./rpatool.py -x llq.rpa

이러면 암호화되었던 것들이 압축이 싹풀리면서 보이게 된다. 그럼 이제 rpatool하고 llq.rpa파일은 필요없어졌으니 삭제하자. 겸사겸사 bytecode.rpyb파일도 삭제해주고.

이제 다시 빌드하고 폰에 넣으면?

 타이틀화면 입성! 게임까지 입성이다!!!

오오..

힘든 사투였다.오오..근데 이 게임을 지하철에서 하는 건 좀 무리 아니려나...

2014. 7 .26 우선 안드로이드 포팅을 하는 방법을 올린 유튜브 영상이다. 본인이 찍었으며 이 방법을 통해서 만들어진 결과물을 마음대로 배포하지를 않기를 바란다. 만들어진 결과물은 개인적으로만 사용하고 꼭 스팀에서 구입한 것을 이용하자. 공식홈페이지에서 구입한 것은...잘 모르겠다.

리눅스 데스크탑에서 매번 겪는 문제중 하나는 바로 한글과 관련된 문제이다. 워드프로세서 한글이 아닌 글자 한글이 문제인 것이다. 지금은 보통 UTF-8이(당연하게도)기본 환경이므로 한글을 띄우는데에 삽질이 필요치 않지만 가끔 EUC-KR을 요구하는 환경이라던지(주로 M$환경에서 작업한 결과물이 이런 식이다.) 아니면 폰트가 가끔 빠져서 한글을 띄우기는 하는데 네모네모네모로 뜬다던지 하는 현상이 일어나곤 한다.

초기 리눅스 민트의 경우 한글폰트가 빠진채로 배포가 되어서 한국어로 설치를 하면 모든 설명이 네모로 나와서 사람을 고생시키곤 했었다. 그런데 리눅스민트도 아니고 한동안 별 문제를 안 일으켰던 우분투14.04에서 난데없는 한글글꼴문제가 터지고 말았는데 이번에는 이전과 반대로 리눅스민트나 다른 데스크탑환경이라면 별 문제는 없지만 Unity환경을 사용한다면 꽤나 치명적인 문제가 되어버렸다. 나는 리눅스민트로 이미 넘어간지 오래지만 안드로이드 관련 개발을 하는 사람들은 그냥 별 생각없이 Unity환경의 우분투를 사용하고있다. 이런 사람들은 배포판을 업그레이드 했다가 멘붕을 조금 먹었다고 한다. 다행히도 이를 해결하는 스크립트가 나왔다고 하는데 이런 일이 있을 때마다 리눅스 데스크탑을 추천해주기가 민망해진다. 이런 간단한 문제조차 삽질을 하게 만드는데 과연 어떤 사람들이 리눅스 데스크탑을 쓰려고 할까?

게다가 리눅스 점유율을 끌어올려줄거라 믿었던 Steam 리눅스용도 약간 한글 문제를 겪고 있다. Steam자체내에서는 문제가 없는데 Steam용 게임들에서 문제가 일어나는 것이다. 한글로 떠야할 자막이 폰트문제로 네모네모로 뜨는 문제다. 특히 Valve사 게임에서 이런 일이 자주 일어나는데 Source엔진의 문제인 것인지 아니면 리눅스환경 자체의 문제인지는 잘 모르겠다. 엉뚱한 폰트를 자꾸 찾는 것 봐서는 Source엔진의 한글지원 문제로 보인다.

윈도에서 압축을 한 파일의 경우에도 리눅스에서 그냥 생각없이 풀어버릴 경우 한글로 된 파일명이 와장창 깨지는 것을 볼 수 있다. 이것은 Repairer라는 노틸러스 확장이나 wine으로 설치한 반디집으로 해결 가능하다. kozip이라는 것도 개발되었고 반디집의 경우 리눅스데스크탑을 설치하면 Playonlinux를 설치한 다음 바로 설치하는 프로그램이기 때문에(alz와 egg지원을 위해서) 딱히 불편함을 느끼지 못한다. 하지만 이것은 어디까지나 유니코드표준인 UTF-8이 아닌 CP949환경을 사용하는 윈도 때문이며 기존의 호환성을 최대한 끌고가는 윈도 특성상 코드가 갑자기 UTF-8로 바뀔일은 없을 것으로 보인다.

폰트의 다양성 문제는 이미 해결이 된 것을 보인다. 과거 백묵글꼴의 경우 매우 가독성 안 좋고 보기 영 안 좋기로 유명 했는데 언제부터인가 은 글꼴이 나오면서 리눅스에서도 굉장히 미려한 글꼴이 가능해졌다. 물론 그 시절에도 저작권있는 글꼴 가져다가 때려박는 사람들이 있기는 했지만 그런 글꼴이 좋았냐고 하면 그건 그것대로 영 아니었던지라 은 글꼴은 순식간에 한글표준글꼴화가 되어버렸다. 지금은 은 글꼴도 아니고 나눔글꼴이 그 역할을 수행중이며 우분투에서 기본 한글글꼴이 되면서 "나눔"이라는 말에 맞게 상당히 많이 퍼지게 되었다. 윈도에서의 굴림같은 존재가 리눅스에서는 나눔고딕이 되었는데 언젠가는 이 나눔글꼴도 새로운 폰트에 자리를 내놓게 될지도 모를 일이다. 어쨌건 그만큼 한글글꼴은 꽤 다양해진 편이다. 이 점은 그나마 다행이라고 생각한다.

하지만 한글과 리눅스는 별로 친하지 않은 것으로 보아 이를 해결하기 위해서도 리눅스 데스크탑의 점유율이 문제인 것으로 보인다. 매번 한글과 관련하여 문제가 터진다는 것은 그만큼 한국인이 개발에 참여하기 어렵다는 의미이며 한글문제를 메일로 날려도 워낙 수가 적어서 이슈화되지 않는 것도 문제다.그나마 Steam은 좀 확인 하는 것으로 보이는데 이게 해결되기까지 얼마나 걸리게 될지는 알 수 없는 일이다.

한국리눅서들은 오늘도 고달픈 삽질중이다.

PlayonLinux를 이용하면 윈도용 프로그램 들을 리눅스에서 쉽게 설치할 수 있습니다. 하지만 이것은 어디까지나 스크립트가 준비된 프로그램들에 한해서 쉬운것이지 한글이나 Solidworks같은 프로그램들은 정말 삽질 아닌 삽질을 해야만 합니다. 특히 CAD들은 제대로 동작하는 것의 확인이 불가능 할 정도로 기능이 다양한데, 필요한 라이브러리들은 정말 다양하게 많습니다. 어쨌건 설치하고 쓸 수 있을 정도로 라이브러리를 설치하는 등의 삽질을 끝냈는데, 만약 배포판 업그레이드나 배포판 교체등으로 시스템을 리셋해야 한다면 Playonlinux로 또 삽질하기가 꺼려집니다. 그래서 PlayonLinux는 백업 도구를 미리 준비해 두었습니다.

이름하여 PlayOnLinux Vault

Vault란 대피소란 의미더군요. 폴아웃에서 나오는 그 볼트 맞습니다. 사실 구버전의 Playonlinux를 사용하시는 분들은 그냥 ~/PlayOnLinux's virtual drives/ 내부를 복사하면 그만이었지만 보안상 문제인지 언제부터인가 복사가 불가능해졌습니다. 심지어 관리자 권한도 안 먹히더군요. 대신에 Playonlinux에 기본 포함된 플러그인중 하나가 바로 이 PlayOnLinux Vault입니다.

사용방법은 아주 간단합니다. 기본 설치 플러그인이기 때문에 메뉴에서 플러그인 - PlayOnLinux Vault를 선택해주시면 됩니다. 그러면 두가지 선택이 나옵니다. Save할 것인가? Restore 할 것인가? Save를 눌러봅시다.

그러면 어떤 프로그램을 백업하고 싶은지 물어봅니다. 선택 후에 Next를 선택하면 전체적인 크기와 Prefix 이름이 나오고 Continue를 하면...

갑자기 어려운 것을 물어봅니다. bz2는 느리지만 압축률이 좋고 lzop는 압축률은 조금 떨어지지만 빠르다고 합니다. 물론 압축안하고 마는 것도 있지요. 이 셋 중 아무것이나 골라주시면 되는데 bz2나 lzop 둘다 라이브러리가 미리 설치 되어있어야 합니다.

sudo apt-get install bzip2 lzop

이후에 저장할 곳을 선택하라고 합니다. 그리고 다음을 누르면 확장자가 poApp이란 파일이 만들어집니다. 만약 백업 이후에 다시 복구하신다면 아까 처음에 Save대신 Restore를 선택하시면 됩니다. 그냥 poApp파일만 있으면 되므로 설치하기 어려운 프로그램같은 것은 이렇게 백업해두는 것도 나쁘지는 않을 것 같습니다.

Android-x86은 초창기에는 그래픽도 가속이 안되고 호환되는 프로그램도 상당히 적었으며 어떤경우에는 비정상 작동으로 작동이 중지되기 하는 말 그대로 테스트 그 이상 그 이하도 안 되는 OS였습니다. 1.6때 말그대로 그냥 돌아가는 것이 신기한 그런 OS였는데 2.3부터 그래픽가속을 시도하더니 4.2 젤리빈에 들어오면서 리눅스와 동일한 KMS도 지원하기 시작했습니다. 4.4킷캣인 지금은 일단 가속이 지원만 된다면야 네이티브로 빠르게 동작하는 안드로이드를 볼 수 있습니다.

문제는 가속이 지원되는 카드가 생각보다는 적다는 것입니다. 초창기 인텔(i915)만 지원하던 때보다야 낫지만 지금도 그렇게 네이티브 해상도를 만들어 내지는 못합니다. 심지어 radeon모듈에서 지원하는 카드의 경우 일부 칩셋에서 정상적으로 동작되지 못하는 현상이 발생하기도 합니다. KMS를 끌경우 부팅은 되지만 화면이 나오지를 않고 KMS를 켜면 화면은 나오나 심하게 깜빡거려서 쓸 수 없는 상태가 됩니다. 문제는 바로 여기서 터진다고 봅니다.

어쨌건 그래픽가속이 되는 순간 해당 x86머신은 안드로이드가 정상적으로 작동하면서 지금까지 만들어져왔던 수많은 모바일 페이지와 모바일 앱을 이용할 수 있게 됩니다. Genymotion같은 가상화 도구 없이 안드로이드 단독 네이티브 OS로써 말이지요.

앱호환성도 많이 개선되었습니다. MX플레이어의경우 x86용 코덱을 따로 제공해주고 있습니다. 이것을 이용함으로써 소프트디코딩도 완벽해집니다. 참고로 x86은 하드웨어 코덱이 그냥 없다고 보는 것이 좋습니다. 가속도 지원이 잘 안 되는 판군에 GPU영상 가속은 그냥 없는 셈 치셔야지요.

그리고 만약 x86바이너리가 지원이 안 되어도 인텔이 ARM호환 라이브러리(libhoudini)를 만들어서 x86기반 스마트폰에 테스트 겸 샘플 겸 넣었기 때문에 이것을 이용하면 ARM바이너리도 실행이 가능해 집니다. 일부 앱은 여전히 작동이 안 됩니다만(대표적인 것이 Unity3D엔진을 이용한 모바일 게임입니다.) 앵그리버드 같은 NDK를 직접 이용한 앱은 거의 잘 작동합니다. 같은 Unity3D라도 아스팔트는 잘 작동하는 것을 보면 게임마다 조금 다를지도 모릅니다.

하지만 libhoudini는 인텔에 저작권이 있으므로 함부로 배포해서는 안 됩니다. 오로지 인텔의 공인된 롬만이 해당 라이브러리를 이용할 수 있습니다. Buildroid나 Genymotion의 경우에는 이 라이브러리를 따로 가상 시스템에 적용하는 것으로 저작권을 피해갔습니다. Gapps와 비슷한 경우이지요. 하지만 이 라이브러리도 안드로이드 버전이 올라갈 때마다 호환성 체크를 해야만 하며 인텔이 2.3진저브레드용 이후로는 제공을 안 하는 것으로 보입니다. 4.0시절에는 2.3호환패치를 따로 적용해야만 이 라이브러리가 작동했던 것으로 알고 있습니다. 지금은 패치가 기본 적용되어 배포됩니다만 여전히 불편하게 따로 적용해야만 하는 것은 동일합니다.

일단 제 예상입니다만 대부분의 안드로이드 어플은 C를 사용하지 않고 오로지 JAVA만을 사용합니다. JAVA만의 어플은 분명 잘 작동할 겁니다. 그건 JAVA의 특성상 바이트코드는 동일하고 자바VM만 포팅되면 어디서든 잘 작동하니까요.

하지만 대부분 게임류나 그래픽작업용 어플은 C가 필수적으로 들어가서 칩셋 호환성 패치가 필요합니다. libhoudini가 어디까지나 강력한 x86칩셋의 힘을 이용했기에 정상적으로 되는 것처럼 보이지 성능이 조금만 떨어져도 엄청 기어가는 모습을 보이곤 합니다. 기본적으로 강력하니까 그냥 묻어버리는 수준인 겁니다. 그도 그럴 것이 바이너리를 번역하는 과정이 필요한데 이게 아무리 빨라봐야 네이티브 작동에 1/2정도로 떨굴 수 밖에 없을 겁니다.

일단 센트리노1.2GHz 2GB메모리 노트북에 작동시켜본 결과 가속이 안 잡혀서 화려한 효과가 들어가는 순간 답답한 화면만이 나옵니다. 하지만 이 정도면 그래도 그럭저럭 인터넷 쇼핑도 가능할 것으로 보입니다. 까놓고 말해서 OSX나 PC용 리눅스보다 안드로이드가 인터넷쇼핑하기에는 100배 낫습니다. 은행도 물론이고요. 브라우저 호환안 된다고 칭얼대봐야 들어먹지도 않는 시절때와 비교하면 많이 발전했네요. 그 와중에 nProtect는 왜 설치하라고 하는 것일 까요. OSX나 리눅스는 윈도나 안드로이드에 비하면 엄청 튼튼하게 만들어진 OS인데 (안드로이드는 프레임워크 버그로 인해 허구한날 보안이 뚫리고 합니다. GingerBreak같은 것이 대표적입니다.)nProtect를 설치함으로써 이 보안이 도리어 박살 나는 것은 아닐지 조심스럽게 고민해 봅니다.

만약 은행업무나 인터넷쇼핑이 필요하다면 가상머신을 이용해서 안드로이드를 돌려보는 것도 나쁘지는 않겠네요. 굳이 그래픽가속 필요없다면 Virtualbox용으로 만들어진 이미지로 바로 구동하면 OSX나 리눅스데스크탑에서도 얼마든지 결제까지 끝낼 수 있습니다. 하지만 모바일 게임은 Genymotion도 그닥 빠르지는 않네요. 쓸만은 하지만 그래도 약간은 모자라 보입니다. 게다가 Genymotion 실행을 막는 게임도 나왔으니 도리어 게임에 쥐약이 될 수 도 있습니다. 그러니까 게임을 제외한 나머지로는 사용 가능이라고 합격점 주고 싶네요.

안드로이드에서 데비안을 쓸 수 있게 하는 어플이 있습니다.

https://play.google.com/store/apps/details?id=com.cuntubuntu&hl=ko

이름은 Debian noroot

어? 왜 noroot가 붙었지? 라고 하시는 분이 있을 것이라 생각되어 한가지 말씀드립니다. 사실 안드로이드에서 리눅스 배포판을 쓰고자 하는 시도는 계속 있어왔습니다. 처음 성공한 것이 chroot를 이용해서 안드로이드에서 arm버전 배포판을 SDCARD에 설치. 커널을 제외한 나머지 라이브러리를 이용하는 방식이었습니다. 특징으로는 X를 설치해도 VNC등의 원격조작을 사용하지 않으면 GUI를 쓸 수 없었다는 것입니다.

이 방법은 chroot를 이용하기 때문에 당연히 안드로이드가 루팅이 되어야만 했고 시스템에 몇몇 프로그램이 돌아가야만 했습니다. 특히 네트워크 관련은 당연히 설치되어있어야 GUI고 SSH고 사용할 수 있었습니다.

하지만 이 어플을 이용한 방식은 조금 다릅니다. SDL을 이용해서 GUI를 바로 안드로이드 화면에 뿌립니다. 즉, 게임 등에서 자주 사용하는 그래픽 라이브러리를 데스크탑 구현에 쓰는 것입니다. 이전에는 우분투를 쓰게 해주었다는데 워낙 우분투가 버벅거려서 데비안으로 바꿔버렸다는 후문이 있습니다. VNC로 GUI하던 방법에서는 워낙 VNC가 느려서 우분투를 이용하든 데비안을 이용하든 사용자경험은 거기서 거기였는데 SDL로 바뀌면서 차이가 생긴 듯 합니다. 아무튼 데비안+XFCE 환경이 설치되며 일단 아쉽게도 사운드는 지원되지 않습니다. 이런 방식을 이용한 프로그램이 따로 이용되고 있는 듯 한데 이것을 이용하는 몇 가지 방법을 알려드리고자 합니다.

1. 오래된 스마트폰 웹서버로 사용하기

오래된 스마트폰은 루팅을 하던지 그냥 쓰던지 상관은 없습니다만 SDL을 사용하면서 GUI로 서버관리가 가능해 졌습니다. 아파치와 PHP를 설치하고 mariaDB를 설치하여 DB를 이용할 수 있게 함으로써 웹서비스에 필수인 3가지는 설치가 바로 됩니다. 여기에 SSH를 설치하면 외부에서 커맨드를 이용해서 관리도 가능해집니다.

즉, 이런 식으로 사용하시면 됩니다.

1) 스마트폰에 Debian noroot 설치 및 실행하여 Debian 환경 구성

2) Debian 진입 후에 루트터미널 실행(XFCE환경이므로 메뉴를 누른뒤에 Application일 터치하면 Root Terminal을 실행할 수 있습니다.)

3) apt-get install ssh apache php5 mariadb

4) 위의 명령어로 ssh와 apache, php5, mariadb 설치

5) ssh를 위해 사용자 설정하기
adduser [사용자이름]

6) /etc/sudoers 를 수정하여 [사용자이름]이 바로 sudo 명령어를 쓸 수 있게 하십시오. 맨 아래줄에

[사용자이름] ALL=(ALL) ALL

이라고 적어주시면 됩니다.

7) 스마트폰의 꺼지지 않게 충전기를 꽂아둘 것. 와이파이가 꺼지지 않도록 설정할 것.

8) 이제 마음대로 웹서버를 굴려봅시다.

2. Gimp를 실행하여 타블렛 비스무리하게 사용하기

1) 문제는 너무 화면이 작은 것입니다. 하지만 근성이 있다면 할 수 있습니다.

2) Root Terminal 실행 후 apt-get gimp 명령

3) 메뉴에서 Gimp실행 참 쉽죠?

3. 리눅스용 게임 즐겨보기

1)물론 x86전용은 안 되고 3D게임도 잘 안 됩니다. 그냥 2D 게임을 한 번 즐겨봅시다.

4. Octave를 이용한 계산하기

Octave는 오픈소스로 만들어진 Matlab클론입니다. Matlab이 궁하신 분들은 Octave를 사용하여 계산이 가능합니다.

1) Root Terminal 실행

2)apt-get install qtoctave

3)QTOctave 실행 물론 그래프로 출력까지 가능합니다.

Debian이 설치됨으로써 가능한 것이 정말 많습니다. 안드로이드폰을 다 썼다고 버리지 마시고 한번 기타 다른 용도로 활용해보시길 추천드립니다. 한번 약정 다 된 스마트폰에 새로운 숨결을 불어 넣어주자고요.

사람들에게 "리눅스가 무엇인지 아십니까?" 라고 물어보면 100중 30정도는 "안다"라고 하지만, 사실은 리눅스가 그저 까만화면에 커서 깜빡이는 그런 텍스트기반의 OS인줄 아는 사람들이 상당히 많습니다. 그도 그럴것이 리눅스 데스크탑의 점유율은 그저 1%남짓입니다. 

참고: https://upload.wikimedia.org/wikipedia/commons/1/1b/Linux_Distribution_Timeline.svg

그렇기 떄문에 리눅스용 프로그램중 오픈소스가 아닌 경우 우분투나 레드햇 같이 메이저한 배포판을 제외하면 "동작하지 않도록 만든 경우"가 많습니다. 사실 동작하지 않게 만든 것이 아니라 라이브러리나 기타 다른 이유로 인하여 "동작하지 않은 것"에 가깝습니다. 대표적인 예가 한글2008입니다. 이제는 지원도 안 해주는 버려진 OS인 아시아눅스만이 한글2008이 정상적으로 동작합니다. 우분투에서 동작하는 팁 들이 인터넷 여기저기 돌아다니고 있지만  우분투의 버전이 올라가면 올라갈 수록 아시아눅스와 차이가 생기면서 이것저것 문제가 생겼습니다.(다른 것보다 프린터 문제가 가장 시급합니다.) 한글과컴퓨터가 한글을 새로운 라이브러리에 맞춰서 다시 컴파일하면 되기는 되겠지만 그렇게 해 줄 리가 없겠지요. 만약 아시아눅스가 지금까지 개발되고 있었어도 한글2008이 우분투나 다른 배포판에서 정상적으로 작동하리란 보장도 없습니다. 왜냐하면 아시아눅스는 아시아눅스 나름의 라이브러리를 이용해서 만들어진 배포판이니까요.

상황이 이러니 리눅스 용 상용 응용프로그램은 거의 전무한 실정입니다. Steam에서 리눅스용 게임을 상당히 많이 팔고 있기는 하지만 엄연히 말하자면 이마저도 리눅스용이라기 보다는 우분투용이라고 보는 것이 더 맞습니다. Valve에서도 우분투에 최적화된 상태로 배포한다고 했으니까요. 페도라에서 Steam과 Steam 플랫폼의 게임들이 정상적으로 작동하는 영상이 보이지만 Valve의 공식입장은 아닙니다. 페도라와 우분투의 차이가 라이브러리 차이가 많이 나지 않아서 작동하는 것이지 한글2008같이 차이가 벌어지면 작동하지 않을 수도 있습니다.

그래서 다들 리눅스 데스크탑의 실패 이유 중 하나가 바로 이 배포판의 다양함이라고 이야기 합니다. 얼핏 들으면 맞는 말 같습니다. 배포판이 다양하다는 것은 그만큼 개발할 때 테스트 장비가 많이 필요하고 개발비가 더 올라간다고 합니다. 이와 비슷한 일이 안드로이드에서도 일어나고 있습니다. 그런데 안드로이드는 그렇다고 개발비가 어쩌고 하지는 않습니다. 왜냐하면 이미 점유율이 상당히 높고 그만큼의 개발비가 회수되기 때문입니다. 결국 "닭이 먼저냐 달걀이 먼저냐"의 문제가 되는데 배포판의 다양함이 문제라고 한다면 우분투나 페도라 어느 하나의 배포판을 기준으로 개발하고 테스트하면 됩니다. (바로 위에서 예를 든 한글2008이 이런 식으로 개발되어졌고 그래서 지금 문제를 일으키고 있는 것입니다.) 그리고 다른 배포판에는 안 팔면 됩니다. 하지만 리눅스 데스크탑의 점유율은 다 합쳐봐야 1% 뿐. 돈이 안 되니까 개발비 운운하는 것 아닐까하는 생각이 듭니다. 개발비가 회수가 안 되니까요.

이렇게 배포판의 파편화가 문제라고 했지만 리눅스의 장점도 또한 이 다양함이라는 것도 참 아이러니 합니다. 선택의 폭이 넓으니 이걸 장점이라고 할 수 있는 겁니다. OSX는 선택의 폭이 참 좁은 OS입니다. 오로지 애플하드웨어만 이용할 수 있으며 인터페이스는 오로지 OSX 본연의 것만 사용 가능합니다. 윈도우는 반대로 레거시 하드웨어까지 지원하는 괴랄함의 극치를 보입니다. 하드웨어의 선택이 상당히 넓으며 최근 윈도8의 인터페이스가 마음에 안 든다고 별도의 프로그램을 이용해서 시작메뉴를 되살리기까지 합니다. 리눅스는 윈도와 OSX 어디에 가까울까요? 그리고 윈도와 OSX 어디가 더 성공한 OS인가요? 제가 생각하기에 리눅스는 OSX보다는 윈도에 훨신 더 가까워 보이는데요. 결국에는 어느 한 배포판이 윈도 수준의 점유율을 먹지 않는 이상 이 문제는 해결될 것 같지는 않네요.

그리고 리눅스라는 것도 엄연히 말하자면 그저 커널의 이름일 뿐입니다. 저 수많은 배포판들을 보면 리눅스는 정말 많은 수를 가진 OS라는 이야기가 됩니다. 하지만, 저건 그저 리눅스를 이용한 OS들일 뿐입니다. 흔히들 리눅스/윈도우/OSX 가 3대 OS라고 합니다. (데스크탑에 한해서 리눅스는 너무 적은 수준이긴 합니다.) 하지만 저는 리눅스는 그저 커널 이름일 뿐이고 각 배포판은 다른 OS라고 생각합니다. 이렇게 되면 각각의 OS점유율이 정말 처참할 정도로 박살나 버리기는 하지만 각 응용프로그램을 어떻게 개발해야할 것인지 알 수 있게 됩니다. 막말로 "안드로이드와 우분투가 같은 OS인가?" 이와같은 질문의 답은 모두 다 "아니오"일 것입니다.  같은 커널을 썼지만 다른 OS취급을 하듯이 우분투와 페도라도 다른 OS이고 우분투기반인 리눅스민트와 우분투도 다른 OS취급을 해야 할 겁니다. 이러면 파편화 때문에 리눅스는 망했다? 절대로 그렇게 생각 못합니다. 리눅스가 망한 것이 아니라 해당 OS가 망한것입니다. 왜냐하면 점유율이 바닥이라서 그렇습니다. 간단한 문제이네요.

아치리눅스, 우분투, 페도라, 오픈수세, 데비안, 기타 다른 리눅스 배포판들. 어느 하나의 배포판만이 성공해야 "파편화"라 불리우는 "OS난립"의 문제를 해결 할 수 있을 것입니다. 하지만 그렇게는 절대로 될 수 없을 겁니다. 당연하게도 그것이 리눅스의 장점이니까요.

http://www.freeantennas.com/projects/template/

이 사이트를 보거나

http://www.binarywolf.com/249/diy-parabolic-reflector.htm

이 사이트를 보면 무선공유기에 반사판을 만들어서 무지향성인 공유기안테나를 지향성안테나로 만들어준다고 합니다. 일단 지향성안테나가 됨으로써 방향만 맞으면 최대 25%정도 성능향상이 이루어진다고 하길래 한번 만들어서 씌워보았습니다. 다만 저는 쿠킹호일이 아닌 알루미늄 테이프로 만들었고 3겹을 덮어주었습니다.

결과는....

차마 스크린샷으로 보여주지 못할 정도로 참담했습니다. 내가 실력이 없는 것인지 아니면 어디부터 잘 못된것인지... 다만 아주 약간 성능이 향상되었습니다. 다만 이건 체감하기 어려울 정도입니다. 이쯤되면 리플렉터보다는 그냥 안테나를 하나 새로 만드는 것이 나을 것 같군요. 아니면 공유기에 끼워넣어준 안터나가 원체 구려서 그럴지도 모르지요.

만약 리플렉터장착만으로 상당히 성능향상이 이루어지신분이 있다면 댓글이나 트랙백을 부탁드립니다.

한컴에서 리눅스용 한컴오피스 뷰어를 배포중입니다. 이제 wine을 이용한 삽질은 안 하셔도 됩니다. 그냥 아래는 참고하세요.

2016. 2.1 한컴에서 한글뷰어를 삭제했습니다!

https://www.dropbox.com/s/6d3thzhum7uul4r/hwpviewer_9.20.0.347_amd64.deb?dl=0

우분투 14.04 64비트용 deb입니다. 일단 이걸 이용하시길 부탁드립니다.

32비트 사용자분들이나 사용상 문제가 있으신 분들은 아래의 윈도용을 쓰셔도 됩니다.

한글2010을 설치하는 방법을 올렸던 이전글 http://moordev.tistory.com/10 을 통해서 Wine으로 적당히 한글2010을 쓸 수 있었으며 레지스트리 조작을 통해 한영전환까지 완벽히 끝낼 수 있었음을 알 수 있었습니다. 그런데 문제가 하나 있다면 HWP를 PDF로 변환하기가 잘 안된다는 거였습니다. 어차피 한글2014도 출시했으니 한글2014를 사기에는 아직 돈이 부족하고(...) 헌컴뷰어2014를 설치함으로써 HWP최신판에 대응할 수 있게 해봅시다.

Wine1.6.2가 역시 현재로써는 가장 안정적으로 돌아가는 것으로 보이기 때문에 "도구" -" Wine Versions Management" 를 통해서 미리 1.6.2를 설치하도록 합시다.

그 다음 http://www.hancomoffice.com/MainServlet 이곳을 통해서 한컴서포터즈에 가입 후 한컴뷰어를 다운로드 받도록 합시다. 한컴오피스2014 평가판도 다운로드 가능하지만 아직 시도해보지 않았습니다. 파일크기가 큰 탓인지 설치를 시도할 때마다 시스템이 멈추더군요. 평가판은 시스템이 안정화되면 시도해보도록 합시다.

한글2010설치시와의 차이는 gdiplus 라이브러리를 따로 설치해주어야 하는 것인데 영상을 보면 Install Some libraries를 선택하여 POL_gdiplus를 통해 라이브러리를 설치하는 것을 알 수 있습니다. 즉, 이것으로 gdiplus를 와인 시스템에 설치할 수 있게 되었습니다. 일단 설치가 끝나고 라이브러리 설정이 끝나면 별 문제없이 실행되며 한컴뷰어를 통해 hwp문서를 확인 할 수 있음을 알 수있습니다.

만약 pdf화를 원한다면 cups-pdf를 설치하여 가상 프린터를 설치한 후에 $HOME/PDF 폴더를 만듦으로써 인쇄기능을 통한 PDF파일 저장도 가능해집니다. HWP to PDF도 리눅스에서 하기 쉬워졌습니다.

다만 한가지 문제가 있다면 정상적으로 완벽 종료가 되지 않아서(태스크바에 한컴입력기와 아이콘이 남습니다.) PlayonLinux의 Close all PlayonLinux software를 통해서 종료를 해야 태스크바쪽에 좀비처럼 남아있는 한컴입력기가 종료된다는 것입니다. 이것만 아니면 별 문제는 없을 텐데 조금 아쉽기는 합니다. 어쨌거나 HWP2014도 이제 최소한 보는것과 인쇄만이라도 가능해졌습니다.

XP의 지원이 끊긴지도 꽤 되었습니다. 사람들은 이제 낡은OS를 버리고 새OS로 갈아타는 중입니다. 대부분 사람들의 새OS가 MS입장에선 윈도8이었으면 매우 좋았겠지만, 윈도8이 아닌 윈도7이란게 MS는 답답한 노릇일겁니다. 7이 8보다 더 비싸니 더 좋을 수도 있겠군요. 

서론은 그만하고 이제 본론으로 들어가겠습니다. XP가 처음 세상에 나온 시절에 기존에 쓰던 프로그램이 돌아가지 않아서 많은 사람들이 혼란을 겪었습니다.여차하면 새pc에 98을 설치하는 경우도 있었으니까요. 윈도의 판매는 윈도의 완성도가 아니라 그 응용프로그램들이 이끈다고 할 정도로 쓰던 프로그램이 안 돌아가면 그 OS가 어떻든 안 씁니다. 리눅스가 아무리 발전해도 윈도를 못 따라잡는게 바로 이런겁니다. 맥도 엄연히 말하자면 osx가 아니라 파이널컷이나 키노트를 쓰기위해 사는경우가 많습니다. (예쁘다고 사는사람도 있기는 합니다.) 

그럼 윈도7은 어떨까요? 일반 사용자들이야 큰 문제는 없습니다. 비스타가 난리를치기는 했지만 비스타를 통해 어느정도 호환성을 확보해서 7에게 넘겨주었습니다. 심지어 드라이버도 호환됩니다. 이정도면 합격입니다만 어디까지나 일반사용자입장에서야 합격이고 산업현장에서는 이야기가 조금 다릅니다. 

산업현장에서는 프로그램상 보통 안정성이 검증된 구버전을 선호합니다. XP기반뿐만아니라 아직도 도스로 관리하는 기업도 있습니다. 그런데 7은 솔직히 검증되었다고 하기에는 조금 부족할지도 모릅니다. 특히 기계컨트롤 관련으로는 관리자 권한이라던가 드라이버 문제로(xp와7은 드라이버가 완벽히 호환되지 않습니다. 어떤문제가 일어날지 모릅니다.) 기존 프로그램을 사용해야 할수도 있습니다. 그리고 일부 프로그램은 설치조차 안되서 호환성설정을 해야하는데 그것마저 잘 안되는경우도 있습니다. 그럼 7호환되는 프로그램을 사야 합니다. 기업들이 좋아할리가 없지요. 아마도 큰마음 먹어야 할 수도 있습니다.

사용자에 따라 큰 차이를 보이는 이유가 무엇일까요? 사실 그 이유는 프레임워크 및 라이브러리부분과 커널단이 차이를 보이기 때문입니다.

프레임워크는 닷넷프레임워크같이 응용프로그램이 돌아갈때 해당 응용프로그램이 돌아가게끔 해주는 일종의 뼈대입니다. 닷넷으로 개발한다고 하면 닷넷프레임워크를 뼈대삼아 이리저리 끼워 맞추는 겁니다. 그런데 윈도는 닷넷만 있지 않습니다. VisualC++로 만든 윈도API기반 프로그램이 더 많습니다. 그런데 이 API가 조금 바뀌어서 다르게 동작한다면? 오류터지는 겁니다. 윈도API를 프레임워크라고 한다면 이 달라지는 것을 갖고 이리저리 패치해야합니다. Wine이 버전에따라 될때가 있다가 안될때가 있다가 하는게 바로 이 api의 구현이 어떻게 바뀌었을지 모르기 때문입니다. Api가 xp와7이 얼마나 다를지는 MS만이 알고 있을겁니다. 아 라이브러리는 이 API가 구현되어진 파일들이고요. directx같은것도 라이브러리입니다.

그리고 산업현장에서 쉽게 OS를 못바꾸게 만드는 원흉인 커널이 되겠습니다.  사실 라이브러리는 패치하기 쉽습니다. 함수형태가 변하는경우는 거의없고 구현이 살짝 바뀌어서 거기맞춰 수정하기만 하면 되기때문에 리버스엔지니어링으로 처리해버리는 경우도 가끔있습니다.(보통은 그럴 필요는 없고 프로그램 제조사에서 금방 대응해줍니다) 문제는 드라이버입니다. 기계들을 관리하는 프로그램들은 드라이버단이 필수인데 커널이 바뀌면 참 대응하기 어렵습니다. 제조사에서 바로 대응해주기도 어렵고요.7은 xp가 못하는 기능이 다수 포함되었는데 파일시스템추가라던가 iso마운트 전력소모 컨트롤 다중프로세스 최적화 등등 그런데 이게 드라이버단에서 꽤나 문제를 일으킵니다. 사운드 드라이버같은것은 별 문제를 안 일으키는데 gpu를 활용하고(cuda같은) 시리얼통신을 하며 특수pci카드같은 장치를 통한방식을 쓴다면 드라이버가 참 말썽을 많이 일으킬것이 뻔합니다. 실제로 xp용 그래픽드라이버를 7에 설치하였을시에 해상도는 잡히지만 발열이 어마어마하게 나며 사망했습니다.... 커널단에서 전력조절을 못한듯 합니다. 그래픽카드야 새 윈도를 당연히 대응해주지만 특수장치 같은경우에는 드라이버를 새로 개발해야 할 정도로 답답해집니다. 그라고 가끔 디스크인식 문제도 벌어진다는군요. 산업용보드같은 경우에는 안정성을 위해 구버전 칩셋에 구형cpu를 다는경우가 많은데 이게 7용 드라이버가 없는경우라고 하더라구요. 산업현장에서는 참 답답할 노릇입니다. OS를 바꾸기는 해야겠지만 기계까지 바꿀수는 없으니...

아마도 이래서 산업현장에서는 범용보다는 임베디드를 선호하는 것일 수도 있겠습니다. 일단 임베디드는 최적화된데다가 OS교체주기가 기니까요. 

갑자기 임베디드하고 범용의 비교가 나왔네요. 기존xp를쓰시던분들은 7교체를 하실때 주변 하드웨어 호환을 고려하셔야합니다. 일반 사용자들은 그냥 지금쓰는 프로그램이 돌아가는지만 확인하시면 되고요. 산업현장은 바꾸는게 능사가 아닐수도 있겠네요.

안드로이드에대한 첫 포스팅입니다. 첫 글부터 조금은 꺼림칙한 이야기를 해야할 것 같습니다.

안드로이드는 아시다시피 점유율1위의 스마트폰OS입니다. 이정도로 성공 할 수 있던 비결은 유저커스터마이징이 자유로웠기 때문이기도 합니다. iOS의 경우에는 오로지 애플이 만들어 놓은것만 쓸 수 있었지만 안드로이드는 오픈소스임을 십분 활용해 조금씩 유저커밋이 이루어졌습니다. 그러다 커스텀롬이란놈이 등장하게되지요. 제조사들과 통신사들의 입맛에 맞춰 마구 헝클어진 시스템을 갈아엎고 AOSP에 가까우면서 각종 유저편의기능들이 추가된 물건이 등장하면서 사람들은 환호했습니다. 그 대표선상에 섰던것이 바로 CyanogenMOD입니다. 제일 두드러졌던 진저브레드시절에도 신기한 기능들이 가득있었지요. 노티바를 아래에 만든다던가 락화면을 없앤다던가. 일단 모든 커스텀롬의 아버지라 불리며 대부분 커스텀롬들은 바로 이 CyanogenMOD를 기반으로 만들어졌습니다. 그리고 무료봉사로 개발자들은 이 CyanogenMOD팀에 커밋을 했습니다. 

그렇게 CyanogenMOD는 킷캣시절까지 계속 만들어왔습니다. 그런데 어느날 CyanogenMOD팀은 상용화를 발표하고 Cyanogen.co라는 회사를 차렸습니다. 그리고 몇몇앱의 소스를 내렸다고 하더군요. 

사람들은 아니 특히 xda개발자들은 분노했습니다. 오픈소스가 상용화되는건 자주 있는 일입니다. 하지만 닫혀진 소스의 일부는 봉사에 의해 커밋된경우가 많아서 CyanogenMOD를 떠나고자 한 사람들이 모여서 대체할만한 롬을 찾게 됩니다. 그게 omni입니다.그래서인지 요새는 omni기반으로 롬이 쏟아져 나오는듯 합니다. Omni도 나쁘지는 않습니다. 다만 과거의 데자뷰가 느껴지는것은 어쩔 수 없더군요.

Openoffice.org의 권한이 오라클에 넘어갔을때 기존 개발자들은 반발했고 이들은 새로운 프로젝트를 만들고 운영하기 시작했습니다. 이게 지금 우분투에 들어가는 LibreOffice입니다. 처음썼을때의 느낌은 오픈오피스에 무언가 빼먹은 느낌? 그런 느낌이 들더군요. 필요한건 다 있기는 한데 무언가 빠진것 같은 애매한 느낌이 들었습니다. 아마도 자바가 빠지면서 해당 기능이 사라지자 느낀 위화감이었을겁니다. omni도 써본결과 비슷했습니다. 무언가 빠진느낌. AOSP에 약간 더 첨가한느낌 그뿐이었습니다. 괘씸하기는 하지만 CyanogenMOD가 더 쓸만해보이더군요. 

하지만 omni는 가벼움을 무기로 삼는듯합니다. 아마도 CyanogenMOD수준의 커스텀기능은 없을지도 모릅니다. 다른롬도 개발되고 있으니 상관은 없겠지만 CyanogenMOD를 버리긴 제가너무 오랬동안 사용해왔던것 같습니다. 개발자들이 떠난 프로젝트는 망하기 마련입니다. 오픈오피스가 그러했기에 제 생각에는 CyanogenMOD보다는 omni를 밀어주는게 당연한 척도로 보입니다. 어떻게 해서든 omni를 적응해야 롬질이 자유로워질것 같습니다.

추가... 만약 커스텀롬 특유의 기능을 쓰려면 xposed framework를 설치하고 gravitybox를 설치하면 된다고 합니다. AOSP에 설치하는게 제일좋다고 하는데 omni는 커스텀된곳이 적으니 크게 충돌걱정없을 것 같습니다.

omni에 xposed framework를 설치해 봤는데 충돌은 없습니다(넥서스7) gravitybox도 설치했는데 시계가 두개가 뜬다거나 하는것 빼면 잘 돌아갑니다.시계가 겹치는것은 gravitybox에서 시계를 없애면 됩니다.

omni에 날개가 달린것 같군요. 아니 이럴거면 그냥 루팅된 스톡롬에 xposed framework설치하는게 나았으려나?