Clojure, Slime 연동시키기

Clojure와 Slime을 연동할 때에는 Swank 서버를 세팅해야한다.
일단 Swank 서버데이터를 가져온다.

git clone git://github.com/jochu/swank-clojure.git

그 다음에 필요한 것은 clojure를 기동시키는 것.. Clojure 기동 파일을 만든다.

#!/bin/bash

CLOJURE=/usr/local/clojure/clojure.jar
CONTRIB=/usr/local/clojure/clojure-contrib.jar
SRC=/home/siabard/project/clojure/src
CLASSES=/home/siabard/project/clojure/classes
SWANK=/home/siabard/src/swank-clojure/src
java -cp $CLOJURE:$CONTRIB:$SRC:$SWANK:$CLASSES clojure.main

이제 Clojure 를 기동시킨후 Swank를 실행시킨다.

(require 'swank.swank)
(swank.swank/start-server "/dev/null" :port 14005 :encoding "utf-8-unix")

포트는 적절히 정리한다.
이제 Emacs 에서 M-x slime-connect 해서 포트를 지정한다. Slime에서 Swank가 호환이 안될 수 있다고 하지만, 무시하고 그냥 진행시키면 된다. 이 메세지가 싫다면

(require 'swank.swank)
(swank.swank/ignore-protocol-version "2009-12-07")
(swank.swank/start-server "/dev/null" :port 14005 :encoding "utf-8-unix")

처럼 해서 프로토콜 버전 체크를 무시하면 된다.

Paul Graham 의 앱스토어 비평

Paul Graham 이 앱스토어에 대해 비판하다.

Paul Graham은 앱스토어를 소프트웨어의 iTunes로 보고 이를 비판하고 있다. 완성된 제품을 시장에 공급하는 음악이나 도서 산업과는 달리 소프트웨어는 지속적인 개발 사이클(iterate)을 가질 수 밖에 없다는 점을 들어, Apple의 이같은 시도가 개발자들에게 중대한 벽으로 작용한다고 보고 있다.

실제로 사용자들이 보고하는 버그를 수정해서 올려야되는 개발자 입장에서는 새로운 버전을 올릴 때마다 다시 심사(Approval)과정을 거칠 수 밖에 없는 것은 90년대 이전의 소프트웨어 시장을 생각케한다. 당시에 많은 패키지들은 한번 나오면 좀처럼 수정이 어려웠기때문에 제작에 상당한 공을 들여야했었지만, 그럼에도 불구하고 수많은 에러를 만들어 사용자를 당황시킨 적이 한두번이 아니었다.

결국 통신망을 통해 지속적으로 패치를 공급하거나 새로운 버전을 빠르게 공급할 수 있었던 업체들만이 살아남을 수 있었다. 문제는 앱스토어의 방식이 이를 근본적으로 금지시킨다는 점이다.

우후죽순격으로 생기고 있는 앱스토어를 보고 있자면, 소프트웨어의 근본적인 특성을 이해하고, 이를 배려하려는 노력이 턱없이 부족하게 느껴진다. 특히나, 날마다 새로운 기능을 요구하고, 변화를 추구해야하는 지금에 있어서, 프로그램 유통자체를 누군가에게 의존해야만하는 모델은 초기에는 제법 괜찮은 것 같겠지만, 나중으로 갈수록 정책이 개발자의 목을 조르는 일이 벌어지게된다.
이렇게 된다면 개발 동력은 저하될 것은 불보듯 뻔한 일이 될 것이며, 언젠가는 구닥다리 버전만 돌아다니는 고물상이 될지도 모른다.

보다 개방적이고, 덜 권위적이며, 프로그래머 친화적인 정책만이 앱스토어를 더억 강화시키는데 일조할 수 있을 것이라고 생각한다.

gifimg.php를 이용한 사이트 해킹

요 며칠간 일부 자바 스크립트가 먹통이 되거나 사이트가 정상적으로 열리지 않는 상황이 발생했다.,
웹쉘, 각종 악성코드를 검사하던 중 이미지를 올려놓는 디렉토리에 gifimg.php라는 정체를 알 수 없는 파일을 발견했다.
해당 파일은

eval(base64_decode(...));

와 같이 한줄만 걸려있으며 인코딩된 문자열을 가지고 있다.
이 코드는 일종의 웹쉘역할을 하지만 실제 공격코드를 가지고 있지는 않기 때문에 몇몇 검색툴에서 정상적으로 잡아내지를 못하고 있따다.

해당 파일은 FTP를 통해서 올려지기 때문에, 보유중인 ftp계정의 암호등을 리셋하는 과정에 더해서, ftp 디렉토리에 걸려있는 모든 드라이브를 검사해보도록 한다.

증상으로는 자바스크립트(*.js)나 PHP, ASP파일등에 특정 URL의 자바스크립트를 호출하는 문장이 끼어든다면 이 문제라고 볼 수 있다.

ferozkhan.in / madam / band_vid.php
art4ukorea.com / data / phpinfo.php
visorg.ru / news / style5.php
cmcludhiana.in / event_image / cmc_ludhiana_hospital.php
psusheela.org / php / index_new_template.php
ecaeda.com / language / Checklist.php

해당 URL에서는 악성코드나 스팸메일을 발송하도록 하는 코드를 수행시켜 자기도 모르는 새 스팸메일의 발송처로 악용될 수 있다.
암호화가 부실한 FTP 사이트를 통해 공격이 이루어지기때문에 웹로그만을 감시하게되면 놓치게 되는 부분이니 유의해야한다.

HTML5 의 Web 게임 가능성..

Google Chrome 이후로 자바스크립트에 많은 관심이 간다.
그중에 하나가 브라우저 상에서의 애니메이션을 제어하는 기술이다.
HTML 5 상에서의 CANVAS로 수행하는 상당히 많은 예제를 보고 있자면 실제로 사용이 가능한 경우가 상당히 많을 것으로 생각한다.
오늘자 Slashdot에서는 플래시 없이 동영상을 VIDEO태그로 실행하는 사이트가 올라왔다. Firefox 3.5 에서만 볼 수 있는 것이 아쉽지만, 앞으로 HTML 5 가 플러그인 시장에 얼마나 엄청난 타격을 입힐지는 기대가 된다.

말하자면 컴퓨터쪽에서의 강력한 연산기능대신 비디오/오디오 등에 특화된 CPU가 있다면, 서버쪽에서 대부분의 연산을 담당하고 클라이언트에서는 웹브라우저가 실제 플랫폼을 대신하는 상황도 생각할 수 있다.

Erlang , LISP으로 만든 게임에서 플레이어 DB데이터와 게임액션을 Erlang이 담당하고, 게임상의 상태처리, 길찾기, API등을 Lisp으로 처리하는 방식은 상당히 좋은 Role Model이 될 수 있을듯하다.

ARM등의 비디오/오디오 강화 CPU에 실연산처리는 클라우드를 포함하는 대규모 서버군이 처리하고, 광대역 처리만 제대로 된다면 기존의 플러그인없이도 HTML 5 만으로도 훌륭한 게임이 나올 수 있을 듯하다.

---

관련링크

• Neuroarena - multiplayer online realtime stratege
• NihilogicLabs의 자바스크립트 마리오 카트
• ypsilon Scheme 구현
• Scheme등으로 게임을 제작하는 회사 Gamerizon
• Clean으로 구성한 게임
• HTML5 비디오 데모 사이트

2등으로 성공하기..

한겨레 21:  2등은 어떻게 살아남는가를 읽고 나서 아웃사이더로 일하는 내가 생각해봐야할 글이라고 생각한다.

원 글에서는 대항마 전략과 체계화 전략을 말해주면서 실제 펩시와 에이비스라는 업계 2위의 업체를 예로 들어 설명했었다. 여기에 내가 생각하는 OS에서의 리눅스, 프로그래밍 언어에서의 LISP을 생각해보았다.

사 실 리눅스 커뮤니티는 오랜동안 윈도를 넘어야한다는 일종의 강박관념을 쥐고 있는 것 같다. 더 적은 리소스, 더 많은 자유, 더 많은 xxx.. 라는 끝도 없는 우월성을 주장하지만 내가 볼 때 가장 먼저 해야할 것은 스스로 한계를 인정해야한다는 사실이다.
이 미 사회에서의 1위는 윈도로 결정이 난 상태이다. 그렇다면, 윈도를 1위로 인정하고 2위로서 1위와 연결하는 전략을 세워야하는 것이 더 적당하다고 본다. 과감하게 2등(현재는 맥에 빌려 3등일지도 모르지만)임을 선언함으로서, 윈도를 분명한 1위 대상으로 인지시키만 (이미 많은 사람들이 공식, 비공식적으로 인정하는 바이다) 자신을 1위와 함께 갈 수 있는 2위로서 자리를 잡는 것이 중요하다고 본다.

예를 들어, 다양한 개발툴을 무료로 쓸 수 있다거나, 서버 테스트 베드로서 아주 훌륭하게 역할을 취할 수 있다거나 하는 점이다. 클라이언트로서는 윈도, 보조툴로 리눅스라는 레벨을 진행한다면 나름 괜찮은 성공을 할 수 있을 것 같다. 이미 집집마다 2~3대의 PC가 기본이 되고 있는 상황에서, mp3나 동영상을 보관할 수 있는 보조적인 부분을 장악한다면 충분한 점유율을 만들 수 있을 것으로 본다.

첫번째 PC는 윈도, 그리고 데이터 보관은 리눅스.. 이런 식으로 대항마 전략을 이끈다면 실제 사람들은 편리하고 간단한 작업은 윈도, 안전하고 신뢰할 수 있는 리눅스라는 식으로 진행한다면 상당한 효과를 줄 수 있을 것이라고 생각한다.

LISP역시 C/C++만큼 속도를 낼 수 있다.. 이런 식의 진부한 강조점을 버리고, C/C++/Java등이 분명한 1위임을 인정하고, 가지고 있는 강점 - 놀라운 추상화 능력이나, 과거에 쌓아두었던 수많은 AI 요소들 - 을 기반으로 협동플레이를 할 수 있다면, 훌륭한 2위자리로 올라설 수 있으리라고 생각한다.

체 계화 전략에서 승부가 갈린 것은 웹에서의 Perl > PHP > Ruby로 이어지는 패러다임의 변화라고 생각한다. 초창기 CGI 패러다임에서 최고의 위치를 자랑하던 Perl을, 간단하고 쉬운 웹 어플리케이션이라는 체계를 완성함으로서 PHP가 끌어내렸고, Rail이라는 걸출한 프레임워크를 무기로 Ruby가 그 자리를 위협하는 것이 좋은 예라고 생각한다.

갈길은 멀다. 아웃사이더중의 아웃사이더 일 (리눅스에서 LISP으로 개발함.. ㅠ.ㅠ)을 계속하고 있지만, 이런 전략을 꾸준히 세워나가면 언젠가 찬란한 2위로 등극할 수 있으리라 생각한다.

오래된 기록 매체...

집에서 몇몇 잡동사니를 정리하다가 5.25인치와 3.5인치 디스켓 몇장이 굴러 나왔다. 예전에 MSX랑 386컴을 쓰던 시절의 게임이 나왔다. 내용물을 확인할 방법이 없어 빛바랜 라벨을 확인해보니  디스켓 게임(이스, D대시, 울티마 6등)과 유틸리티(코렐 드로우, PCTools등)였다. 아마도 어딘가에는 이 때 쓰던 각종 데이터가 들어있을 디스켓이 있을 것이다. 지금으로서는 확인이 불가능하지만...



386컴을 처음 샀을때가 92년이었다. 대학교 입학 선물로 엄청 큰 돈 들여 집에서 구매해주셨고, 덕분에 4년 내내 각종리포트랑 게임을 하면서 - 물론 바로 곧이어 등장한 486에 힘없이 떠밀리지만 - 컴퓨터쪽으로 밥을 먹게 되는 단초가 되었으니,추억이라면 훌륭한 추억이 될지도 모르겠다.

처음에 컴퓨터를 본 것이 국민학교-초등학교라는 말은 아직도 어색하다-5학년때, 친구집에서 본 삼성 SPC-1000 이었다. 이 기종에는 테이프 리더가 붙어 있어서, 각종 프로그램을 테이프에저장하고, 로드할 수 있었다. 지금보면 웃음밖에 안나오지만 당시에는 짧으면 5분에서 길분 한시간 넘게 기다려서 게임을 로딩하고,실행되는 것을 보면서 정말 엄청나게 즐거워했다. (물론 한시간 넘게 로딩해서 에러가 나면 다시 도루묵이 되버리는 바람에뒤집어지는 상황은 불유쾌하지만 말이다.)

당 시에 사용하던 테이프랑 롬팩(가장 처음 사용해봤던 컴퓨터는 대우CPC-800이던가로 기억한다. MSX 기종이었다)은 아직도 집 한켠에 자리 잡고 있지만, 이 데이터는 이제는 돌려볼 수가없다. 미디어가 맛이 가는 것은 둘째치고, 테이프나 롬팩을 읽을 수 있는 장비가 내게는 존재하지 않는 것이다.

불과 20여년 만에 특정 기록매체를 확인할 방법이 거의 사라져 버린 것이다.
만약 집에 테이프, 롬팩, 5.25인치 디스켓, 3.25인치 디스켓을 가지고 있다 하더라도, 이 매체 안의 데이터를 확인해보려면 꽤나 불편한 과정을 거쳐야한다거나 어쩌면 아예 볼 수 있는 기기가 사라져버릴 수도 있다.

플 로피 디스켓이 나오면서 테이프 저장매체는 자리를 잃었고, 이번에는 CD가, 곧이어 DVD가 계속 나오게 되었고, 마침내 현재에는USB같은 매체가 주류를 이루게 되었다. - 하드 디스크는 아직 그 자리를 굳건히 지키고 있지만 SSD같은 매체가 위협을 하고 있다.

지금 가지고 있는 매체안의 데이터를 얼마나 오래 사용할 수 있을까?
데이터가 파괴될지 모른다는 위험은 둘째치더라도, 당장 지금 저장한 데이터를 읽을 기기가 언젠가 사라질지도 모른다는, 정말 상상할 수 없는 상황이 언제든지 벌어질 수 있다. 예전에 각종 데이터를 저장해뒀던 플로피 데이터를 현재 사용할 수 없는 것처럼 - 매체의 데이터 보존성은 차치하더라도 - 지금 우리가 사용하는 USB데이터는 수십년, 아니 수년안에 읽을 수 없을 미래의 모습은 충분히 가능할 것이다.

얼 마나 많은 데이터를 모으고 축적할 것인가에 대해서는 잘 알면서도, 우리가 현재 사용하는 데이터를 어떻게 남겨야 시간이 지난 후에도 이 데이터를 사용할 수 있을 것인가에 대한 논의는 너무나 미약한 것 같다. 과연 우리 자손이 우리가 소소하게 남기는 각종 데이터를 그 때에도 충분히 참고할 수 있을까?

어떤 사람들은 인터넷을 통해 충분히 수많은 데이터를 보존할 수 있다고 말할지도 모른다. 하지만 서비스하는 회사가 사라지는 순간, 수많은 데이터는 너무나 어이없이 사라지는 모습을, 너무나 흔하게 보고 있다. 추억이 어린 사진, 치기 어리지만 순순했던 시기의 글들, 당시에는 너무나 치열하게 고민했던 생각들... 이런 기록을 10년, 20년이 지나 누군가가 볼 수 있을지는 여전히 불확실하다. 네띠앙이나, 하이텔같은 서비스가 접히면서 얼마나 많은 기록들이 접근하기 불가능하게 되었는지는 상상도 할 수 없을 정도니까..

우리가 가진 기록매체를 얼마나 신뢰할 수 있을까? 현재 나오고 있는 출판물이라고 해도, 그 보존기간은 수십년을 넘기가 어렵다. 수천년전에 진흙에 쐐기로 새기고, 구워서 남긴 고대의 기록이나, 조상들이 남긴 서책들앞에, 한순간에 불면 날아갈 것 같은 우리의 기록은 왠지 초라한듯한 생각이 든다.

Windows 7 to Ship in Multiple Versions?

Tom's hardware의 뉴스에서 읽었다.

The five versions of Windows 7 are as follows: Starter, Home Basic, Home Premium, Business and Ultimate.

이렇다는 얘기다. 현재 나와있는 베타 버전은 Ultimate 버전에 준한다고 하는데.. 다른 여타의 버전에서는 여러 가지 기능이나 차단막이 쳐질 것 같은 분위기인데...

2000, XP, 2003, Vista같은 경우에 여러가지 버전이 있었는데 개발하면서 더 까탈스럽기만 했던 것 같다. Program Files에 대한 접근 문제가 불거졌던 XP 의 경험같은 것이 아직도 생생한데 , 다섯가지 버전 설치에 맞는 가이드라인을 잡으려면 꽤나 고생할 듯한 기분이 든다.

누구를 위한 버전 분리인지는 두고 봐야할 듯 싶다..