한컴에서 리눅스용 한컴오피스 뷰어를 배포중입니다. 이제 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설치하는게 나았으려나?