computer

IRC나 메신저나 회사나 여러군데서 컴퓨터를 할 줄 안다는
이유로 워드 질문, 윈도우 세팅 질문, 인터넷이 왜 안되느냐 질문,
메일이 왜 도착 안 하느냐 질문, 다음넷에 왜 로그인이 안 되느냐 질문 등.. 별의 별 질문을 다 받습니다.
“내가 만든 것 아니라 몰라요” 라고 대답할 수도 없고.. -_-;;

하여간.. 그래서 지금까지 했던 답변 중 시스템과 관련된 질문 대부분을 커버할 수 있는
일반해를 하나 고안하였습니다. 시스템 질문 중의 한 80% 정도는 이 일반해
공식으로 해결이 될 것 같군요.. 🙂 물론 워드질문이나 웹사이트 왜 안되느냐 하는 질문에 대한 일반해는 너무 어려워서 아직 만들지 못했습니다. –;;

• A: XXX가 안 돼요.
  B: XXX가 어떻게 안 되나요?

• A: 잘 모르겠어요. 그냥 XXX가 안 돼요.
  B: 에러 메시지 없나요?

• A: 안 보여요 하여간 안 돼요.
  B: 로그에 뭐 안 남나요?

• A: YYY라고 나와 있어요. (YYY는 단정적인 최종 에러 메시지)
  B: 그 위에는 뭔가 없나요?

• A: ZZZ라고 나와 있어요. (ZZZ는 에러의 이유 또는 상황)
  B: ZZZ를 따옴표로 감싸서 구글에 쳐 보세요.

• A: 뭔가 나오긴 하는데 읽기 귀찮아요. 하여간 고쳐줘요.
  B: 첫번째 것에 마우스를 가져간 다음에 왼쪽 버튼을 클릭해 보세요.

• A: 뭔가 나오긴 하는데 읽기 귀찮아요. 하여간 고쳐줘요.
  B: 그 밑에 써 있는 명령 (또는 환경설정 예시)을 따라 쳐 보세요.

• A: 오.. 뭔가 되는 것 같긴 한데 그래도 안 돼요.
  B: 그냥 무작정 붙여넣지 말고, 자기 설정에 맞게 바꿔서 쳐보세요.

• A: 오.. 뭔가 되긴 되네요. 감사합니다. B씨는 역시 천재예요. 다음에도 또 물어볼께요.
  B: 다음부터는 저한테 물어보지 말고 구글한테 물어보세요.

• A: 몰라요 구글 싫어요.
  B: -_-…

몰라요 구글 싫어요. 라는 말을 들었을 때, 대상별 반응..

• 자주보는 친구가 “구글 싫어요” 했을 때 => 다음에 밥 사달라고 한다.
• 띄엄띄엄보는 친구가 “구글 싫어요” 했을 때 => 다음에 내가 부탁할 것이 있는 일도 있겠지 하면서 분을 삭인다;;
• 친한 친구가 컴퓨터 잘 아는 사람이라고 자기가 아는 사람을 소개시켜 줬다 => 친구한테 내가 낯가림이 많다고 얘기한다.
• 모르는 사람이 “구글 싫어요” 했을 때 => 모르는 사람이라 다행이라고 생각하고 참는다 -.-;
• 후배가 “구글 싫어요” 했을 때 => 아직 세상을 잘 모르는구나 생각하고 구글쓰는 법을 가르쳐 준다.
• 선배가 “구글 싫어요” 했을 때 => 큰일이다. 앞으로 무슨 일이 있을 것 같으면 막 밥먹으러 가려던 참이라고 한다.
• 부모님이 “구글 싫어요” 했을 때 => 가족애를 생각하고 세대차이를 생각하면 그래도 계속 열심히 가르쳐 드려야겠다는 생각이 든다.
• 여자친구가 “구글싫어 으아앙T-T 웩” 했을 때 => 귀엽다. 안아준다.

(먼산)

으흐흐~ 요새 불여우 플러그인인 All in One Gesture를 써 보면서 음청나게 좋구나! 하고 막 감동하고 쓰고 있었습니다. 물론 프비에서는 gtk2의 영향으로 뼈저리게 느리게 드륵드륵 거리지만;;;

제가 할 줄 아는 GUI 툴킷이 윈도우밖에 없다보니까, 윈도우에서 이런 것 있으면 무척 편리하겠다 하고 생각해 봤는데, 역시나 검색을 해 보니 벌써 굉장한 것이 있군요;; StrokeIt이라고 하는 것인데 꽤 오랫동안 관리된 프로그램이고 최근까지도 업데이트가 활발히 되고 있습니다. 물론 가볍고 커스터마이즈도 무척 잘 되어있네요. 게다가 이벤트를 직접 프로그램해서 넣을 수 있게 SDK까지 제공하고.. 긱스럽기가 아주 X용 오픈소스 프로그램들 수준이군요.. (라이선스는 비상업적 목적에 한해 바이너리 사용 가능이고, 소스는 공개되어 있지 않습니다.)

흐흐.. 그런데, 상당히 많은 언어로 번역이 되어 있는데 한국어 번역이 없길래 그냥 한번 번역해 보았습니다.

번역 파일 다운로드

흐흐 저자에게 보내줬으니 곧 공식 사이트에서도 받을 수 있겠지용 ‘ㅇ’

오늘자 시사 매거진 2580에서는 얼마 전에 있었던, 스파이웨어를 통한 비밀번호 추출로 남의 계좌를 이체해버린 사건을 문제 삼아서, 국내 전자상거래/은행 보안의 문제점을 조명했습니다. 중간에 phpBB도 나오고 한텀도 나오고, 주변에서 보인 재미있는 것들이 많이 나오네요. 🙂

그렇지만, 데이터 전송 경로를 하드웨어에서 어디서 어디로 전송한다고 그림을 보여주거나 막 신비롭게 껌껌한데서 불꺼놓고 로그 보고 있다거나.. 뻔한 해커 영화의 시각이나 똑같이 표현을 했는데.. 정말 볼 때마다 새로워요. -_-;; 나도 불 끄고 코딩할까? -O-;

그런데, 여전히 2580에서는 마치 패스워드 보안은 정상적인 상황에서도 마구 남의 것을 볼 수 있고, 스파이웨어가 설치된 후에도 은행 솔루션 업체들이 어떻게 잘 노력을 하면 막을 수 있는데도 안 막고 있는 냥 얘기를 하고 있습니다. 그렇지만, 사실상 대부분의 윈도우 사용자가 커널레벨까지 조작을 할 수 있는 관리자 권한으로 사용한다는 점을 고려하면, 은행 프로그램들이 무슨 발악을 하더라도 소프트웨어적으로는 패스워드가 노출되지 않을 수가 없는 당연한 상황이라, 역사적으로 보더라도 항상 공격자가 이기는데 뭐 어떻게 막을 방법이 있겠어요? 흐흐..

결국, 이런 상황을 해결하려면, 외부 하드웨어의 도움을 빌거나, 역순해시를 사용한 일회용 패스워드를 사용해야 한다는 결론에 도달합니다. 즉, USB로 연결된 외부 카드 리더에서, 카드의 인증서를 읽어서 컴퓨터 측에서 요청한 자료를 싸인한 뒤에 결과 패킷을 보내준다던지.. 일회용 패스워드를 100개 은행에서 발급해 와서, 그걸 순서대로 하나씩 사용한다던지.. 흐흐.. 하여간, 얼른 소프트웨어적으로도 뭔가 해결할 수 있다는 환상을 버리고, 사회적인 방법이나 외부 하드웨어 장치의 도움을 법적으로 모든 금융/전자상거래에 의무화를 한다고 주장합니다! 물론, 스펙은 공개해서 독립적 구현도 충분히 진입할 수 있게.. 🙂

주의: 이 글은 개인적인 해석이며 법적인 정확성을 보증하지 않습니다. 구체적인 저작권, 특허, 상표권에 대한 문제는 원문을 참조하세요.

어제 공개된 OpenSolaris
소스를 보다 보니, 생각보다 재미있고 뜯어 쓸만한 부분이 꽤 많이
있었습니다. 🙂 그래서, 이제 열심히 갖다가 썼는데 뒷통수 맞는
일이 없도록 라이선스인
CDDL (Common Development and Distribution License)을 자세히
읽어보았습니다.

CDDL은 우선 전체적으로 GPL같이 아주 딱딱하게 조절된 무서운
어조로 써 있지 않고, 그냥 통상적이고 상식적인 수준의 문장으로
되어 있어서 읽기가 편하다는 면에서는 좋군요. 분량도 애플 것에
비해서 짧고.. 🙂 우선, 첫 부분의 용어 정의 부분에서는 대부분
상식적인 용어와 비슷한데, 몇가지 다른 것이 있다면 이 정도가..

• “Executable”: 소프트웨어에서 소스를 제외한 모든 파일
• “Larger Work”: CDDL하에 있는 작업외에 다른 라이선스로 된 큰 작업을
  조합한 작업

CDDL에서는 독특하게 최초 개발자(Initial Developer)와
기여자(Contributor)를 명시적으로 구분해서 권한을 따로 정의하고
있는데, 재라이선싱 권한 외에는 크게 다른 점은 없어보이는군요.
그리고, 다른 라이선스들 (특히 GPL)에서는 특허와 관련된 말들은
최대한 언급을 삼가하고 있는데, CDDL에서는 라이선스 하에 있는
소스를 작성한 모든 기여자들과 최초 개발자들 사이의 특허 문제까지도
명확하게 정의해서, 모호함을 없앴다는 점은 장점으로 꼽힐 수도
있겠습니다.

우선, BSDL과 GPL, Artistic License같은 오픈소스 라이선스 분파들을
서로 비교할 때 사용되는 여러가지 일반적인 특징은 배포, 수정, 판매
등의 다른 조건들은 비슷하지만 라이선스를 동의하는 조건이 조금씩 다른데,
CDDL에서는 이런 조건들을 걸고 있습니다.

• 소스코드 같이 배포: “Executable” 상태 (즉, 소스 코드가
  아닌 모든 포맷)로 배포를 할 때에는 항상 소스 코드를 CDDL하에
  배포를 해야 한다는 강제 조건이 있습니다. 즉, 이 부분에 대해서는
  GPL과 여러모로 유사한 면이 있다고 볼 수 있습니다.
• 변경: 원래 CDDL하에 있는 소스를 변경한 부분에 대해서는
  모두 CDDL의 영향 하에 가도록 되어 있으며, 변경자는 그 작업 부분이
  자기 고유 작업임을 밝혀야합니다.
• 변경 고지: CDDL하에 있는 소스를 변경한 사람은 반드시
  자기가 변경했다고 기여자 목록에 표시를 해야합니다. 기존의 다른
  오픈소스 라이선스들은 이 부분에 대해서, 반드시 고지해야된다는
  얘기는 따로 안 써있는 것들이 대부분이었는데, 원래 소스에서 변경된
  것을 원 저자가 만든 것처럼 표시되는 것을 막기 위해서 넣은 부분인
  듯 합니다.
• 추가적인 사항: 다른 오픈소스 라이선스들은 호환되는
  것들에 대해서는 추가적으로 다른 라이선스를 적용할 수도 있게 되어있는데
  CDDL에서도 품질보증이나 추가 제공같은 것들을 추가로 넣을 수는 있지만
  이것들이 원래 CDDL에서 보장되는 것들을 해쳐서는 안 되며, 원저자와
  원기여자들이 품질보증이나 추가 제공에 전혀 관련이 없다는 것을
  명시적으로 표시해야합니다.
• 바이너리 배포: 소스코드가 아닌 형태로 배포하는 경우
  CDDL이 아닌 완전히 새로운 라이선스로 배포도 가능합니다. 즉,
  xchat처럼 소스는 GPL이고, 바이너리만 상용이고 이런 것도 충분히
  가능하다는 얘기겠죠. 단, 이 경우에도 라이선스를 받은 사람은
  소스를 요구해서 CDDL하의 소스를 받을 수 있습니다. 🙂
• “Larger Work”: 다른 큰 소프트웨어와 섞이는 경우, 예를
  들면 openssl과 apr을 이용해서 mod_ssl같은 게 나오는 것 같은 경우가
  되겠죠. 이런 경우 섞임으로 인해서 최종 생산물이 CDDL을 침해해서는
  안 된다는 확인이 있어야 합니다.

그리고, 예전에 애플에서 한번 시도해서 문제가 되었던, 라이선스
개정시 조건도 같이 업그레이드라는 그런 것은 좀 더 자유롭게 되어서,
썬에서 라이선스를 개정하더라도, 처음 소프트웨어를 받을 당시의
CDDL 버전을 쓸 수 있습니다.

재배포를 하는 경우 반드시 소스코드를 배포해야 한다는 점에서,
BSD에서는 /usr/src/gnu/ 디렉토리에나 들어갈 만한 라이선스라
좀 섭섭하기는 하네요. 으흐흐. 그래도 뭐 썬도 먹고 살아야~ -O-

그동안 거의 베이퍼웨어 수준으로 뜸을 들이고 있던 OpenSolaris가 드디어 소스를 공개했군요. 타이틀 화면의 “열린”이 아주 멋있습니다. 🙂

bz2로 압축해서 44메가 정도되는 솔라리스 소스 중에서 가장 기대하고 있던 부분인 iconv소스를 얼른 쳐다 봤습니다. 🙂 솔라리스의 iconv는 다른 iconv와는 달리, 변환 루틴부분을 위한 별도의 언어를 정의한 뒤에, 그 소스를 C로 컴파일하는 구조로 되어있어서 확장에 매우 유리하게 되어있는데, 현재 아주 구리구리한 구조로 되어있는 FreeBSD iconv를 고치는데 이런 방향으로 해 보면 도움이 될 것 같습니다. 소스를 뒤져보니까 usr/src/cmd/geniconvtbl/ 안에 메타언어 컴파일러가 들어있고, libc 소스 안에 iconv가 들어있는 간단한 구조로 되어있는데, 소스 구성이나 레이아웃 등이 BSD와 크게 다르지 않은 편이라 앞으로 좋은 장난감이 될 것 같군요.

iconv외에도 gettext나 멀티바이트 API 같은 FreeBSD가 약한 부분들 뜯어다 쓰기에 요긴할 것 같은데.. 라이선스가 FreeBSD에서 섞일 수 있는 것으로 판단이 될지 좀 두고 봐야겠네요..

회사에서 워크샵을 가면서, 상황 극복을 위한 발전 방향이나 내부의 커뮤니케이션 문제같은 여러가지 것들을 토론했습니다. 지난번 워크샵까지는 그냥 먹고 놀았는데, 이번엔 진지한 토론도 하고 역시 많이 발전을.. 🙂

명함이나 회사 양식지 같은 여러 곳에 있는 회사의 슬로건은 “Open Source Experts”입니다. 그런데, 뭐 사실 회사가 생긴지 만 6년이 다 되어가지만, 오픈소스회사가 할 만한 일은 하나도 한 일이 없다고 봐도 되겠지요.. 전문가라면 쏙쏙 빼먹기만 해도 되남? 흐흐. 하여간 이런게 상황이 매우 어려운 회사 실정에는 호사스러운 불평일 수도 있겠지만, 그래도 아무도 얘기하지 않으면 그냥 그래도 되는 것이 되기에 용기를 내어 한번 말해 보았습니다.

그렇지만, 뭐 역시 답변은 “회사가 망하고 나서 오픈소스를 해 봐야 무엇하나”, “우리나라 사정에는 오픈소스로 돈 벌 수가 없다”, “오픈소스를 해야지만 오픈소스 회사인 것은 아니다” 이런 식의 늘 들어왔던 말들이었지요. 사실 이런 생각을 갖고 있는 사람들을 설득하기란 쉽지 않습니다. 오픈소스를 전혀 처음 접한 것이 아니고 이미 오해를 단단히 하고 있기 때문에 거부감을 이미 충분히 가지고 있는 상황이라 생각을 바꾸기가 쉽지가 않지요.

사실 자신이 오픈소스를 잘 알고 있다고 생각하면서 거부감을 가지고 있는 경영자들의 오해는, 회사가 오픈소스를 하면 처음부터 무조건 레드햇같이 회사의 모든 제품을 오픈소스해야 하는 줄 아는 것이 주가 됩니다. 사실 제품 전체를 통짜로 오픈소스로 만드는 지미안이나 레드햇, IBM같은 곳도 있을 수는 있겠지만, 그런 비즈니스 모델을 적용해도 회사 재정에 문제가 없을 경우에나 그렇겠지요. 반면에 Google Code나 Yahoo Search Developer Network처럼 프러덕트 전체를 오픈소스화하는 것은 아니고, 회사의 이익은 유지할 수 있으면서도 세계 개발자원의 절약에 큰 도움을 줄 수 있는 이런 오픈소스화를 할 수도 있습니다. 회사 주력 제품을 개발하면서 부산물로 나오는 것은 사실 구글이나 야후만 하는 것이 아니라 FreeBSD 소스만 보더라도 수십개의 비-오픈소스 회사가 소스를 기부해 왔고, Python 소스에서도 10여개의 회사가 자신들의 목적에 맞춰서 일정부분의 소스를 기부해 온 것을 볼 수 있습니다.

즉, 오픈소스라고 해서 굳이 목숨걸고 할 필요는 없다는 것입니다. 만약 대용량 메일 솔루션을 만든다면, 그 안에 들어간 서버 프로세스들을 위한 IPC 프레임워크를 공개한다고 해서 메일 솔루션 팔아 먹고 사는데 과연 지장이 있을까요. 오픈소스는 사실 그냥 회사의 도의적 정당성만 형식적으로 주는 것은 아닙니다. 회사의 코드들을 오픈소스화 함으로써, 회사 자체의 관리 부담이 줄어들고, 오히려 외부에서 새로운 기능을 추가해 준다던지 버그를 잡아줄 수도 있는 효과도 노려볼 수 있습니다. 또한, 해당 오픈소스 부분을 사용하는 곳이 많아지면, 비슷한 라이브러리나 모듈을 사용하는 프로그램들끼리의 호환성도 쉽게 올라가서, 오픈소스에 기여하는 회사들끼리 상호운용성이 크게 향상됩니다. 그리고, 오픈소스를 함으로써 개발자들에게는 “내가 이 회사를 다닌다. 우리 회사 라이브러리 써 봤어?” 하고 자부심을 가질 수 있어서 사기충전에도 큰 도움을 주며 새로운 개발자들을 유혹하는 긍정적인 요소가 될 수 있습니다. 개발자들 대부분은 자기 소스를 마음대로 자랑할 수 있을 때에 코드 품질이 훨씬 올라간다는 점에서 품질의 향상에도 영향을 줍니다.

저희 회사에서 점진적인 오픈소스가 진행되지 못했던 점은 물론 개발자들이 능동적으로 릴리스를 하려는 의지가 부족했던 점도 있습니다. 그렇지만, 사실 그렇게 주장을 하더라도 오픈소스 개발자들의 개발 방식과 생활 방법이나 의식은 회사 생활에는 안 맞다는 생각이 이미 마음 속 깊이 있는 관리자들에게 말이 받아들여질 수 있을 지는 의문이군요.. 그냥 며칠 안 남은 병역특례가 얼른 끝나기를.. 🙂