블로그

권순선의 이미지

개발자를 위한 nFORGE & DVCS(git/hg) 활용 세미나

네이버 개발자 센터의 기반이 되는 오픈소스 협업 플랫폼 nFORGE가 3.1 정식 버전 릴리즈를
준비하고 있는데 이번 버전에서는 분산형 소스코드 버전 관리 시스템(DVCS)인 Git과 Mercurial을
기본적으로 지원하게 될 예정입니다. 이에 발맞추어 협업개발 & 분산형 버전 관리 시스템에 관심
있는 분들과 함께하는 시간을 가지고 서로의 경험과 생각을 즐겁게 나누고자 합니다.

시간
- 2011년 6월 9일 (목) 오후 4시 ~ 7시

장소
- 공간더하기 (강남역 7번 출구에서 1분 거리)
- http://www.spaceplus.co.kr
- 전화번호: 02-501-3298

wkpark의 이미지

익명성에 대한 소고

요사이 KLDP가 익명으로 되어서 익명으로 간간히 댓글을 달고있는데, 또 익명에 관련된 이야기가 나와서 예전에 KLDP.net 모니위키 프로젝트에 올렸던 글이 생각났습니다.
http://kldp.net/projects/moniwiki/issue/315710

사실 익명성에 대해서 별다른 생각이 없었는데, 엔하위키를 보면서 익명성에 대해서 다시 생각해보는 계기가 되었습니다.

현재 엔하위키는 모니위키 1.1.5+엔하위키 패치로 운영되고 있는데, 작년에 10만페이지가 못 되었던것 같은데 현재 11만 페이지가 되어있네요.
모니위키로 운영되고 있는 위키중에 제일 큰 위키가 바로 엔하위키입니다.

그런데 재밌는 것은 엔하위키의 대다수 편집자 분들은 익명으로 활동하고 있다는 사실입니다. 엔하위키에 올라가는 글들이 다소 민감한(?) 사항도 있기때문에
개인의 프라이버시를 침해하지 않기 위해서 거의 위키에 상주하다시피 하시는 분들조차도 익명으로 활동하고 있지요.

joone의 이미지

Ubuntu 11.04 with GNOME3

http://www.ubuntugeek.com/how-to-install-gnome3-on-ubuntu-11-04-nattyubuntu-10-10-maverick.html

11.04부터 많은 변화가 있습니다. 기존 GNOME Desktop대신 다른 Desktop환경이 사용됩니다.
전 그 대신 GNOME3를 설치했습니다. 적응하는데, 좀 시간이 필요하지만, 여러 창을 관리하는데는 더 효과적이네요.

다즐링의 이미지

Fuji Xerox DocuCentre-IV C2270 을 우분투에서 사용하기

최근에 데스크탑으로 리눅스를 쓰는 사람이라면 알것이다.

대부분의 프린터는 그냥 바로 잡힌다.

( 혹은 나처럼 고대부터 사용해온 사용자들은 잘 잡히는 것을 산다. -_-;;; )

그런데 프린터를 세팅하려고 보니.. 안잡히는 거다.

기존에 후지 제록스의 프린터를 사용해본 적이 없기에 고민하다가 구글에 검색된 매뉴얼을 보니 일어 페이지가서 받으라고

제일 작은 폰트로 되어 있다. -_-;; 게다가 한국어 홈페이지에는 않나온다.

http://www.fujixerox.co.jp/download/apeosport/download/c4300series/linux/

일단 가서 구글 번역기님의 힘을 빌어서 받아보니.. fxlinuxprint-1.0.3-1.i386.rpm 라는 파일을 받았다. 어라 -_-; rpm 이군..

feanor의 이미지

LevelDB

LevelDB는 구글의 Jeffrey DeanSanjay Ghemawat이 만든 key/value DB입니다.

key/value DB는 많이 있습니다만 두 사람은 위 링크에서 알 수 있듯이 Google File System, MapReduce, BigTable 등을 만들었기에 좀 자세히 살펴보았습니다.

gurugio의 이미지

CPK 2.3.5

도배해서 죄송합니다. 합쳐서 올리면 너무 길것 같아서 나눠서 올립니다.
관심좀..굽신굽신 =)
------------------------

gurugio의 이미지

CPK 2.3.4

2단계에서는 빌드와 관련된 모든 정보를 하나의 파일에 모아서 처리해보았습니다. 그런데 아직도 하나가 각 Makefile에 남아있습니다. 바로 빌드 명령입니다. 실제로 컴파일러, 링커를 호출하는 빌드 명령이 각 Makefile에 남아있고, 누군가가 실수로, 혹은 잘 몰라서, 아니면 잠깐 급해서라도 이 명령을 손대면 전체 제품의 빌드에 문제가 생길 수 있습니다. 이번에는 아예 빌드 명령까지 분리해서 각 서브 디렉토리의 Makefile에는 이 디렉토리의 최종 산출물에 대한 정보만 저장되도록 만들어보겠습니다.

gurugio의 이미지

CPK 2.3.3

빌드 순서를 생각해보면 configure는 프로젝트를 빌드할 플랫폼에 대한 정보를 얻습니다. 그리고 make가 실행되면서 make에 지정된 옵션에 따라 빌드가 시작됩니다. 따라서 실질적으로 빌드 프로세스를 조정할 수 있는 것은 make의 옵션입니다. 따라서 make의 옵션을 인식해서 옵션에 맞게 빌드를 진행할 수 있도록 Makefile을 작성해보겠습니다.

gurugio의 이미지

CPK 2.3.2장

먼저 아주 단순한 Makefile을 작성해보겠습니다. GNU make가 제공하는 매크로는 사용하지 않고, 개발자가 모든 명령을 직접 Makefile에 써주는 형태를 보여드리겠습니다.

가장 먼저 만들 것은 소스 트리의 가장 상위 Makefile입니다. 지금부터 소스에서 가장 상위 디렉토리가 현재 디렉토리라고 가정하겠습니다. 따라서 가장 상위의 Makefile은 ./Makefile이라고 표시됩니다. 다음은 ./Makefile의 내용입니다.

# config.mk is generated by configure
include config.mk

all:
make -C src
make -C test

clean:
make -C src clean
make -C test clean

gurugio의 이미지

CPK 2.3.1장

빌드 과정을 준비하기 위해 빌드 대상이 될 소스를 몇개 만들겠습니다. 소스가 저장되는 디렉토리는 src와 test가 있습니다. src 디렉토리는 CA라이브러리에 들어갈 소스들이 저장됩니다. 그리고 test 디렉토리는 CA라이브러리의 각 API를 테스트할 유닛 테스트 소스들이 저장됩니다.

현재는 configure에서 생성해준 플랫폼 정보가 있으므로 이 정보를 알려주는 API를 만들어보겠습니다. 그리고 이 정보를 화면에 출력하는 유닛 테스트를 만들어보겠습니다. 엄밀히 말하면 유닛테스트 프로그램이 화면에 데이터를 출력하고 끝난다면 테스트로서 의미가 없지만 실행 파일을 빌드하는 예제를 만들기 위해서 그렇게 만들어보겠습니다.

다음은 src/sys_info.c 입니다.

/*********************************************************************
* $Id$
*********************************************************************/

#include
#include

페이지

RSS - 블로그 구독하기