그냥 삼x 메모리를 선택할 수 밖에

오늘은 어찌어찌 해서 아침 일찍 일어났다. 조금 뒹굴다가 문득 고장난 PC 가 생각이 나서, 원래는 다음 주에 택배로 수리를 보내려고 했는데 그냥 용산에 직접 가기로 마음먹었다. 날도 덥고 습하고 해서 움직이기 망설여지고 지하철 요금이 조금 아깝다는 생각은 들었지만, 간만에 용산 분위기도 좀 볼 겸 해서 집을 나섰다.

서비스센터에 도착해서 확인해 보니 PC는 정상이다. 고장났던 것은 메모리였다. 바로 이거...

그런데... 디직스가 망했나 보다. 할 수 없이 간 김에 그냥 메모리를 하나 샀다. 삼x 제품으로. 처음부터 삼x 제품으로 살걸 하는 후회가 든다. 워낙 삼x이 싫었던 것도 있었고, 반면에 당시 디직스에 대한 세간의 평이 좋았기에 선택했었는데, 뜬금없이 메모리 위에 붙어 있는 보증 스티커의 태극기... 태극기를 내세우는 것 치고 제대로 된 경우를 본 적이 없었는데 역시나 이런 사태가 벌어졌다.

국산품 애용 표어를 들으며 자란 세대이지만, 언제부터인가 국산이라고 요란떠는 제품에 대해 오히려 신뢰할 수 없다는 생각이 들기 시작했다. 특히 태극기를 내세우고 하는 것은 더 그랬던 것 같다. 게다가 디직스 메모리의 칩은 국산이 아니다. 처음부터 평생보증이니 뭐니 하는 사탕발림은 믿지도 않았었다. 기계적인 구동부도 아니고 메모리 고장은 20여 년 동안 컴퓨터를 접해 보면서 처음 겪는 일이다.

32bit JVM java.net.UnknownHostException

어떤 테스트케이스를 실행하는데 자꾸만 test error 가 발생한다. fail 이 아니고 error. 나는 아무것도 바꾸지 않았는데... 사실 바꾸긴 바꿨는데, 전혀 상관없는 부분에서 에러가 발생한다. ESMParserTest 라는 곳이다.

어찌 되었건 무엇 때문에 에러가 발생하는지는 알아야 해서 찬찬히 살펴보았더니, UnknownHostException 이다. 왜일까? 표준 DNS 에 등록해 놓은 호스트인데.
/etc/hosts 파일 안에 해당 도메인과 IP 주소를 매핑해 놓았더니 더 이상 에러가 발생하지 않는다.
이렇게 해결하는 것은 근본적인 해결책이 아니다. 그럼 대체 왜 발생할까?

GWT 플러그인이 64bit linux 용은 아직 없어서 32bit JVM 을 지정하여 사용하고 있는데 32bit JVM 에서 에러가 발생한다. 그렇다면 M$ 의 32bit JVM 에서는 왜 에러가 발생하지 않고 잘 돌아갈까? 한 번 64bit JVM 에서 테스트케이스를 돌려 보니 정상적으로 통과한다.
이럴수가. 어떻게 한군데씩 꼭 문제가 있을까?

슬프게도 역시 M$ 에서 개발을 해야만 하는 것일까? 모처럼 힘들여 64bit 환경에서 안 되는 GWT 개발을 32bit 로 맞추면 되기에 불만스럽지만 겨우 적응해 나가고 있었더니 새로운 문제가 발목을 잡는다.

OSX용 화면 분할 소프트웨어, TwoUp

요즈음 대세인 와이드 모니터는 너무 넓다고 생각하게 되는 경우가 있다. 영화감상보다는 문서(코딩) 작업이 주가 되어 놓아서 넓은 화면보다는 긴 화면이 더 절실한데 그렇다고 모니터를 돌려놓을 수도 없는 것이, 내 모니터는 Cinema Display HD 라서...

다만 모니터가 넓다 보니까 어느 순간부터인가 화면을 반으로 나눠 양쪽에 문서를 열어 놓고 작업하는 사람들이 있는 모양이다. 창 배치를 수동으로 하다 보니 이게 너무 귀찮아서 그런 기능이 나온 것 같은데, 이게 애플에는 기본으로 되어 있지 않는 것 같다. 그리고 근시일 내 나올 모 운영체제는 전혀 흥미가 없지만 이 기능이 기본으로 탑재되어 있어서 살짝 부러웠다.

그러던 어느 날 눈에 띄는 문장... position windows to fill exactly half the screen.. 원하던 그 것이이다. 게다가 프리웨어... 이 곳에서 받을 수 있다.