Everyday I have the Blues

MS 사용자 그룹이 오페라 제품 불매운동 벌이다

  개인적으로 오페라 캠퍼스 크루의 1인으로서(현재도 오페라 티를 입고있는... 쿨럭=3=3) 당연히 약간 관심가는 포스트였는데, 생각보다 MS 유저그룹의 주장이 꽤나 타당하다. 문제의 상황은, MS가 유럽에서 반독점 문제로 까이고있고, 이제껏 문제가 되었던 IE 끼워팔기에 대한 논란으로부터 시작한 것인데...

  MS측은, '윈도7 설치시에 IE8 설치여부의 선택권을 사용자에게 주겠다'라는 주장으로 반독점 문제를 피하려 하고 있으며, 반독점 소송을 건 업체들 측은, 그것만으로 부족하고 애초에 윈도7 패키지에 오페라, 파폭, 크롬, 사파리 등등 다 포함시켜서 어떤 브라우져를 쓰고싶은지 선택하도록 해야한다... 는 뭐 각각 그런주장이다.

  이에대해 MS사용자 그룹의 주장이 '이건 마치 펩시콜라 캔에다가 코카콜라 프로모션하는 격이다' 라는 건데, 윈도7 설치를 위해서 MS의 제품이 아닌것들을 리스트를 나열하고 사용자에게 보여준다는게 어쩌면 맞는 말인거 같다.

  자 그럼, 이제 여기서부터는 내생각인데 나는 개인적으로 오페라 소프트웨어를 위시한 반독점 소송을 건 업체측의 주장이 더욱 타당하다고 본다. 이유인즉 브라우저라는건 다른 소프트웨어와는 조금 다른, 매우 특별한 경우로 볼 수 있기 때문이다.

  그렇다면 도대체 무엇이 특별한가. 가정하기를, MS의 주장대로 IE의 사용여부만을 사용자가 선택할 수 있다고 해보자. 나는 IE가 쓰기 싫어서 윈도7을 설치할 때 IE를 빼버렸다. 윈도우 설치가 끝나고, 오페라를 깔기위해 오페라 사이트에 접속하려고 한다. 응? 어떻게? 브라우져를 다운받기 위해서는 일단 브라우져가 있어야겠는데? 최소한 사이트는 들어가야 할게 아닌가.

  브라우져를 제외한 다른 대부분의 소프트웨어는, 자사의(혹은 파폭같은 경우 재단의) 오피셜 사이트를 통해서 배포할 수 있다. 그래도 아무런 문제가 없다. 그러나 브라우져는 설사 새로운 배포방식이 개발된다고 하더라도 사용자에게 그것에 익숙해지기를 바라기도 힘들며, 대부분의 일반 사용자들은 그러한 새로운 방식의 학습에 대한 의욕이 없다. 따라서, 오페라를 비롯한 다른 브라우저를 깔기 위해서는 일단 반드시 IE부터 깔아야되는 아이러니한 상황이 발생하는거다. 즉, IE설치를 강제하는거나 다를바가 없다는거지.

  그렇기에 나는 반독점 소송측의 주장이 훨씬 타당하다고 보는데... 뭐 어디까지나 내 생각.

거의 포기하고 있었는데 이런게 있다. 6월 12일자 통과면 오늘이란 소린데, 진짜 출시되려고 저러나.

찾아보니 모델명 A1241이 아이폰 3g 블랙 16기가랜다.

진짜 나올건가봐...

(떡밥!) 

나만큼 노력하지 않고는 그런 말 하지 말라.

  원문은 KLDP에서 "나빌레라"라는 아이디로 활동하고 계신 분이 쓰신건데, 최근에 "도전! 임베디드 OS 만들기"라는 책을 쓰셨다. 근데 알고보니 SPLUG 분이시더라.

  여튼간에 마찬가지로, 내가 가장 듣기 싫어하는 소리 역시, "형은 원래 잘하잖아요" 이다. 물론 내가 나이가 좀 어리므로, "넌 원래 잘하잖아" 하는 얘기도 많이 듣는다. 뭐 그소리가 그소리지만, 세상에 원래 잘하는게 어딨나. 그래서 내가 그만큼 같이 하는 소리가 "딱 나만큼만 노력해라. 그러면 못해도 나만큼은 할꺼다" 이다.

  세상에는 나보다 실력없는 수많은 사람들이 있고 그들의 공통점은 "나만큼 노력하지 않았다"는 것이다. 마찬가지로 세상 천지에 널려있는 나보다 잘하는 사람들의 공통점은 "나보다 열심히 했다" 라는 것. 뭐 물론 그중에는 특별히 머리가 뛰어나서, 사실 나보다 열심히 하지 않았는데 나보다 잘하는 사람이 있을수도 있다. 그러나! 어차피 그런사람은 극소수에 불과하다. 결론은 사람 다 똑같다는거지.

  나의 노력은 내가 즐기는만큼, 내가 잘하고 싶은 만큼이며, 더 잘하고 싶은 욕심이 아직 마르지 않아서 요즘도 책을 보고 공부하고 고찰한다. 정말 재미없는데 억지로 하는거라서 나만큼 노력할 수 없다는 소리를 하고 싶다면, 그럼 난 이런얘기를 하겠다. "한살이라도 어릴 때 때려 치워라".

  고등학교 때 힘든 입시공부하는 것과 대학공부는 분명히 다르다. 뭐 방법이 없고 길이 없는건 아니지만, 거의 대부분의 경우 대학 전공으로 평생의 직업과, 진로가 정해지는 경우가 많다. 그리고 막말로 대학 4년을 컴퓨터 전공으로 살았다면, 아무리 하기싫고 재미없어서 컴퓨터를 못한다 할지라도, 다른건 더 못할거 아닌가. 그나마 들은 풍월이라도 있는건 컴퓨터밖에 없게 되므로, 그 힘들던 대학 4년과 마찬가지로, 어쩌면 더 지옥같은 느낌으로 평생을 살아야 할꺼다. 세상에 적성에 안맞고 재미없고 하기싫은데 어렵기까지 한 일을 평생 해야 하느것 만큼 고문이 또있을까.

  만약에 그런게 아니라면, 뭐 할만하고 재밌는거 같다는 생각이 듣다면, 그럼 좀 열심히 해보면 안될까. 요즘같이 좋은 환경에, 나처럼 컴파일러 한번 써보겠다고 주변에 컴퓨터라고는 아는 사람 한명없는 촌구석 섬동네에서 2박 3일 밤새고 앉아서 리눅스 깔고 그래야 할 일도 없지 않은가? 문제 생기면 물어볼 사람도 많잖아. 도서관 가면 공짜로 책도 볼 수 있는데. 나처럼 밥 굶어가면서 책 값 모아서 한권 두권 아름아름 살 필요도 없고, 큰 서점 찾아가서 틈틈히 조금씩 읽고 나오는 그런 쪽팔린 짓도 안해도 될텐데.

  이런 좋은환경에서 갖출거 다갖추고 시작하는 사람들이, "형은 원래 잘하잖아요" 이딴 소리나 하고 자빠져 있으면 내 기분이 어떨까.

Android on x86 스크린샷

  x86 머신에 안드로이드를 올리고나서 가장 많은 삽질을 했던 부분이 바로 마우스였는데, 뭐 그냥 마우스가 정상적인 동작을 안한다는 것이었다. 뭐 클릭 이벤트는 발생하지만 모션 이벤트는 씹어버린다던지, 여튼 고따위의 문제였는데 결론은 파워 부분의 문제였다. 파워 스테이트에 따라 특정 이벤트들에 대해 필터링을 하는데 거기에 걸렸던거. 여튼 코드는 다 들어가있는데 왜 안될까의 삽질에 삽질을 거듭하다 결국 파워에서 kernel config 하나 수정함으로 해결되니 뭔가 기쁘기보다 허무했다. 

  우찌됐던간에 사실 이런 일이 있었던 것은 좀 된 일이고, 귀찮아서 포스팅을 미루다가 이제야 한다. 마우스 문제를 고치면서 얻은건 안드로이드의 Input device event 구조를 한번 훑었다는 것과, 기본 마우스 패치에 이벤트중에 휠이 포함되어 있지 않은데, 추가해보니 너무 간단하더라는 뭐 그런 느낌?

  여튼 이 포스트의 목적은 애초에 안드로이드의 Input device event에 관한 것이었으나, 회사에선 너무 포스팅만 하긴 좀 그렇고, 집에와서 포스팅 하자니 코드가 회사에 있고 하는 이런 여러가지 아이러니한 상황속에 고민하는...(집에서도 다운받으면 되지만 귀찮다능)

  그래서 생각나는대로 대충 지껄이면 다음과 같다.

* 파일(머릿속에 떠오르는대로 적는거라 경로가 틀릴수도... - 수정)
1. frameworks/base/core/java/android/view/RawInputEvent.java
2. frameworks/base/libs/ui/EventHub.cpp
3. frameworks/base/services/java/com/android/server/WindowManagerService.java
4. frameworks/base/services/java/com/android/server/KeyInputEvent.java

뭐 대충 이정도...? 각각의 파일에서 어떤 일이 이루어지는지 대략적으로 보면

1. RawInputEvent.java : 뭐 하는건 없고, 각각의 이벤트 종류에 따라 디바이스에서 날려주는 keycode, scancode 등이 상수로 정의되어 있다.

2. EventHub.cpp : 실제 인풋 디바이스들(/dev/input/* 파일들)에 대해 polling하다가 넘어오는 이벤트 타입, 코드, 값 등을 상위로 넘겨준다. 물론 디바이스에서 읽어올 때는 struct input_event 타입으로 읽어올테고, 상위에 넘겨준다는건, 자바쪽에서 jni로 연결해서 읽는거다.

3. WindowManagerService.java 발생한 이벤트에 대해 동작을 처리하는 부분. mQueue.getEvent로 검색하면 이벤트 큐에서 이벤트를 읽어와서 switch로 각 이벤트에 따른 동작을 분기하는걸 볼 수 있다.

4. KeyInputEvent.java : WindowManagerService.java의 mQueue는 KeyQ 클래스의 객체고 KeyInputEvent는 KeyQ의 수퍼 클래스다. 이 안에서 쓰레드를 돌며 jni로 연결된 EventHub로 부터 RawEvent를 얻어오고(소스에서 readEvent로 검색), 그 keycode, scancode, type에 따라 이벤트 객체를 만들어 이벤트 큐에다 박아준다.

ㅇ ㅔ... 사실 처음 생각할 떈 속속들이, 정말 신급의 포스팅을 하시는 분들처럼 line by line으로 분석해가며 글을 써보고 싶었으나, 역시나 귀찮은 관계로 이정도로 마무리. 뭐 생각해보니 학부 2,3 학년 이상 수준이면 금방 알아볼만한 내용이지 싶다.