역시나 까탈이는 오늘도 까탈스럽게 굴었습니다. 이유는 잘 모르겠지만 fglrx가 설치된 우분투에서 wine을 설치하려하니 fglrx를 지워야 한다고 뜨더군요.

이건 또 뭔가 하니까 wine 1.6이후에 추가 패키지로 설정된 opencl관련 패키지가 fglrx를 지우려고 드는 것이었습니다. 마음 같아서는 오픈소스로 갈아타고 싶었는데 아직 오픈소스 드라이버가 안 나온 상황이라(비마 기반 APU입니다.) 어쩔 수 없이 fglrx에 기댈 수 밖에는 없습니다.

 어쨌건 저랑 비슷한 상황이 있는 듯 하는 사람이 많은 듯 하여 일단 wine만 무시하고 설치하는 법만 알려 드리겠습니다.

 http://askubuntu.com/questions/540780/14-10-wine-and-fglrx-conflict

출처는 여기입니다.

 여기서는 fglrx의 패키지 설정을 바꾸는 것으로 해결하기도 하는데 그건 그거대로 삽질 같아서 wine을 그냥 강제로 설치하는 것을 알려드리겠습니다. 어차피 opencl은 fglrx 설치하면서 다 설치 되어서 필요없거든요.

 우선 wine을 deb형태로 다운로드 받습니다.

sudo apt-get download wine1.6-amd64 wine1.6-i386 wine1.6 playonlinux

여기서 playonlinux는 따로 설치하려면 설치하시고 아니면 굳이 설치 안 하셔도 됩니다. 그리고 32비트 사용자 분들은 wine1.6-amd64는 지워주세요.

이제 다 다운로드가 되었는지 확인 되셨으면 설치를 해야겠지요? 여기서 일부 옵션을 넣어줍시다.

sudo dpkg --force-all -i *.deb

이제 강제로 설치를 하려고 할텐데 그냥 메시지는 무시하셔도 됩니다. fglrx가 다 설치해 놓은 것들입니다. 구동에 아무런 지장 없습니다.

하지만 제일 좋은 것은.... fglrx를 안 쓰는 것이 가장 좋다고 생각합니다. Gallium3D가 제 칩셋을 빨리 지원해 주길 기다리면서....

2014. 1. 2

 지금 확인해보니 wine때문에 패키지 설정이 꼬여버립니다. 그냥 Playonlinux를 설치해서 이를 이용합시다. 처음 실행할 때 wine이 없다고 뭐라 뭐라 할텐데 가뿐히 무시하고 Wine versions기능으로 wine을 따로 설치해서 굴리면 됩니다.(단, PlayonLinux가 저장소에 있는 구버전이면 안 됩니다. 이건 Wine을 무조건 적으로 설치합니다.) 즉 System wine을 안 쓰면 된다는 소리.

아니면 fglrx의 패키지 설정을 수정해도 문제는 없을 것이라 믿습니다. 그런데 OpenCL 관련해서 문제가 일어날지도 모르기 때문에... 일단 Gallium3D 드라이버가 나올 때까지 기다리는 걱이 최선인듯...

2014.2.

 이미 오픈소스 드라이버는 나와있었습니다. 그동안 검색 부족과 14.10을 거들떠도 안 본 죄로(...)몰랐던 것일 뿐. 그냥 커널을 3.15로 올리고 Xorg를 PPA를 통해 버전업하면 됩니다. 아니면 oibaf PPA를 이용하시면 안정적이면서 편리한 드라이버를 설치하실 수 있습니다. 그러니까 쉽게말해서 그냥 Catalyst를 버리시면 됩니다.

제목은 한글문제입니다. 이번에 이야기 할 것은 한컴의 워드프로세서가 아니라 우리가 지금 사용하는 바로 이 한글을 말합니다.

리눅스는 아시다시피 오픈소스로 공개된 커널을 기반으로 이리저리 손을 대서 만들어낸 물건입니다. 따라서 모든 세계인들이 활용 할 수 있게 만들어야 하고 또 그렇게 되고 있습니다. 그런데 워낙 리눅스 이용 인구가 적은 한국은 한글 문제에 자주 봉착합니다. 아니 한글 자체가 문제가 아니라 UTF-8과 EUC-KR의 호환문제, 게다가 Microsoft만 만들고 쓰는 CP949같은 코드 파편화 문제입니다. 사실 한글을 읽고 쓰는 것은 전혀 문제가 없습니다. 유니코드라는 국제 표준이 나오면서 전세계의 언어를 통합 관리하게 되었기 때문에 이 유니코드만 사용한다면 한글문제, 아니 전세계의 모든 언어의 문제는 해결이 가능합니다.

문제는...... 표준을 지키지 않는 것들입니다. 저는 "비표준"이나 "사실상의 표준"을 참 싫어합니다. 비표준이야 어쩔  수 없는 경우가 많다고 해도(예를 들면 M5.5같은 애매한 나사라던가....이건 M5나 M6을 쓰면 안 되나?) 사실상의 표준이라고 이를 고수하는 것도 좀 웃기다는 생각이 듭니다. 사실상의 표준이라면 이를 표준으로 지정하면 되는데 ISO에서 이를 표준으로 지정하지 않는다?

대체 무엇이 문제일까요? 대표적인 것이라면 플래시가 있습니다. 브라우저 플러그인 방식인데다가 멀티코어 사용에 문제가 있고, 어느 한 회사(Adobe)의 독점 형태로 제공되고 있다 보니 문제가 참 많습니다. 하지만 그래픽적 효과를 이렇게 쉽게 보여줄 수 있는 녀석도 없어서 플래시는 지금 웹 그래픽에서는 표준이다시피 합니다. 하지만 HTML5에서 플래시의 기술은 들어가지 않았습니다. 넣으려면 넣을 수도 있었을텐데 말입니다. 그 이유는 모바일 플래시를 써보신 분들은 아시겠지만 엄청난 연산량에 따른 문제라고 하는군요.

그러고보니 반대로 한 회사에서 만들어서 쓰다가 ISO의 표준지정으로 바뀐 기술도 있습니다. 바로 PDF! 그러고 보니 이 물건도 Adobe의 결과물이군요. PDF는 현재 문서표준으로 지정되어 있어서 모든 기술이 공개되어있습니다. 위의 플래시 기술이 완전공개가 되지 못한 것(플래시 기술의 일부는 공개가 되어있습니다. 오픈소스의 결과물이라고는 하지만...)과는 차원이 다르지요.

자 다시 한글 표준으로 돌아와서 이제 어떤 문제가 있는지 확인 해 봅시다. 먼저 MS는 CP949라는 뭔가 해괴한 EUC-KR호환 한글코드를 사용합니다. 그 와중에 내부에서는 유니코드를 사용합니다. (뭐하는 짓이야...) 그리고 KS표준에 보면 EUC-KR과 유니코드를 동시에 올려놓았습니다. 그리고 UTF-8이라는 유니코드와 아스키 호환 코드도 존재합니다. ISO는 당연히 유니코드만이 표준입니다.

네 점점 가관입니다. 특히 KS표준이 참 막장이네요. EUC-KR과 유니코드를 같이 표준으로 채택하는 바람에 통일이 이루어지지 못했습니다. 그럼 CP949는? 이건 표준 아닙니다. 그냥 MS가 만들어낸 확장 완성형 기반입니다. 마치 옛날에 조합형 vs 완성형 싸움 비슷한 생각이 드는군요. 현재로써는 완성형이 이긴 것 같기는 하지만 한/글 워드프로세서가 조합형을 썼기에 지금의 위치에 오른 것을 생각해보면....

이러한 문제는 멀리 갈 것도 없이 UTF-8을 기본으로 사용하는 리눅스/OSX에서 윈도에서 압축한 ZIP파일을 풀면 여실히 드러납니다.한글 파일명이 대책없이 깨집니다. CP949는 EUC-KR 호환이라고 했지요? 원인은 여기있습니다. 때문에 반디집같은 프로그램은 UTF-8환경을 한번 거치는 것 같기는 합니다만,(한글이 아닌 다른 외국어로 쓰인 파일명을 읽기 위함 그런데 이것이 UTF-8에서 압축한 한글에도 먹히는 것입니다.)

언제나 매번 문제를 일으키지만 해결될 기미가 안 보이는 한글문제... ISO의 권고사항만 지키면 큰 문제는 없을 것 같은데 왜 안 지키는 사람들이 많을까요? 제발 적당히 배운티 내지 않았으면 좋겠습니다.

이번에는 무진장 딱딱하고 재미없는 글을 올릴 차례입니다. 물론, 지금까지 재미있는 글은 없었지만 이번에는 더 딱딱한 이야기를 해보려 합니다.

많은 사람들은 아직도 리눅스를 엄청 딱딱하고 어려운 운영체제로 알고 있습니다. 원인이야 뻔하지만, 리눅스를 사용해본 사람들은 리눅스 자체가 어려운 것이 아니라 사용 방법이 틀렸다는 것을 알고 있습니다.

사실 리눅스를 데스크탑 운영체제로 사용하게 된 것은 그리 오래되지 않았습니다. 리눅스는 사실 서버 워크스테이션에 쓰이던 Minix의 카피였고(리누즈 토르발즈 자서전에 나와있습니다.) 그 리눅스라는 커널보다 사용자의 완전 분리라는 독특한 매력에 사람들이 빠졌다고 합니다. 즉, 한 컴퓨터에 여러사람이 달려들어도 서로 다른 환경을 쓰는 것 같은 느낌을 줬다고 합니다. 윈도 사용자분들은 1인 1PC시대에 살고 있는데다가 보통 관리자 모드로 사용하기 때문에 (UAC로 어느 정도 막고는 있지만)어떤 것인지 잘 모르겠지만, 관리자는 따로 있고 사용자들은 오로지 User모드만 사용하는 것이지요. 어떤 프로그램을 설치하고 싶으면 관리자에게 연락해서 설치해 달라고 해야 했고, 그 관리자의 계정은 언제나 root였기에 root계정이 해킹당하면 말그대로 시스템이 장악되었습니다.

무슨 소리인지 잘 모르겠다고요? 그냥 당시의 컴퓨터는 원격으로 접속해서 사용해야만 하는 컴퓨터였고(그래서 워크스테이션이라고 따로 지칭한 것입니다.) 이 때 관리자와 유저는 엄격히 구분되어야 했습니다. 사실 Unix시스템의 전반이 다 그러했습니다. 그런데 리눅스가 어렵다는 편견은 아마도 여기서 시작된 것 같습니다.

사실 윈도는 윈도XP시절부터 사용자를 제대로 분리하기 시작했습니다. 그전의 98시절에도 충분히 사용자분리 옵션은 있었지만 바탕화면이 공유되는 등(...) 말도 안되는 사용자 분리를 택했기 때문에 아무도 그런 기능이 있었는지도 몰랐습니다. 심지어 어떤 사용자모드를 쓰더라도 시스템의 근본까지 장악 가능했으니(리얼 도스모드 진입가능→ 하드웨어 직접 접근 가능)사용자 분리의 이점이라고 눈꼽만큼도 없었습니다. 대신 그만큼 개인이 신경 쓸 거리는 줄기는 했습니다. 그러다가 윈도NT계열이 가정용으로 들어오면서(즉, XP시절 이후를 말합니다.) 기존 NT가 했었던 것처럼 사용자 분리를 시도했는데 현실은 그냥 유저 구분없이 모두함께 관리자 모드로 사용... 윈도 비스타시절부터 UAC란 놈을 들고와서 관리자 권한이라도 경고를 한다던가 한번 필터링을 하는 방식도 취해봤지만 이미 전반적인 생태계가 관리자 권한을 요구하는 괴상한 형태로...

즉, 윈도 사용자들은 권한 분리가 익숙하지 않습니다. 그에비해 워크스테이션으로 시작된 OS인 리눅스는 이를 엄청 중요시 여깁니다. 관리자 권한 해킹당하면 해당 워크스테이션을 사용하는 모든 사람들의 정보가 전세계로 솟구칠테니까요.(혹은 삭제당하거나) 처음 리눅스란 것을 본 사람들은 여기서 짜증을 내기 시작했'었'습니다. 왜 과거형이냐면 기존 윈도 사용자들이 UAC덕에 관리자 권한으로 실행하는 것에 익숙해지기 시작했거든요. 물론 아직도 UAC가 뜨면 당황하는 사람들이 태반이기는 하지만 이제 좀 관리자 권한에 대해 이해를 하기 시작한 사람들이 보입니다. 그런 사람들에게 리눅스를 보여주고 su나 sudo 혹은 gksu같은 명령을 알려주면 그게 "관리자 권한으로 실행"이라는 것을 곧잘 이해하더군요.

(물론 아직도 이해 못하는 사람 많습니다. 왜 관리자 권한이 필요한 이유조차 모르기 때문이지만...)

그런데 우분투같은 사용자 편의를 중시한 배포판에서는 언제부터인가 관리자 권한 확인이 UAC 비스무리한 모습으로 만들어지더군요. 즉, 권한분리에 익숙치 않은 사용자들을 위해서인지 그냥 권한 분리를 윈도스럽게 해놓았습니다. 우분투가 쉽다고 하시는 분들 중에는 이러한 이유도 있습니다. 다른 배포판에서는 기본 세팅상태를 기준으로 유저모드로 sudo 명령을 쓰면 대부분 안 먹습니다!(데비안이나 페도라 기준) 우분투처럼 쓰고 싶으면 /etc/sudo내의 있는 설정파일을 수정해야만 하고 수정을 하려면 root로 로그온 해야합니다. 즉, 관리자의 손길이 필요하다는 것이지요. (이 이야기는 데비안 기준이고 페도라는 좀 다르다고 알고 있습니다.)아, 대신 우분투는 root권한 자체가 숨겨져 있습니다. 마치 윈도에서 Administrator계정이 안전모드에서만 나오는 것과 비슷합니다.

이쯤되면 리눅스는 어렵다는 것은 일부 배포판에 한정해서이기는 하지만 조금 완화 되었을 것이라고 생각이 듭니다. 자신의 정체성 중 일부를 수정하면서 까지 윈도스럽게 수정했으니까요. 소프트웨어의 부재는 전에도 말했듯이 wine이나 Virtualbox로 극복이 가능한데다가 전용 소프트웨어도 상당히 훌륭합니다.예전에는 제품개발은 어쩔 수 없이 윈도에서 했지만, 요즘은 제품개발도 리눅스에서 가능해져 가고 있습니다.(DraftSight와 CATIA의 wine 실행 - 이놈은 태생이 유닉스 용입니다.)

리눅스가 어렵다는 것은 편견이라고 했습니다. 리눅스의 대표적인 데스크탑 배포판인 우분투는 이미 윈도 사용자를 상당히 배려했습니다. 그런데도 많은 사람들은 리눅스를 어려운 운영체제로 믿고 있습니다. 일단 까더라도 사용해보고 깠으면 좋겠습니다.