한빛출판네트워크

리눅서는 어떻게 크는가?
이제 초보 리눅서에게 도움이 되는 이야기를 하기로 하자. 무슨 일이든 기본이 있고 원칙이 있다. 이 것을 지킨다면 빨리 그 분야에 적응할 수 있다. 리눅서가 되기 위한 원칙은 어떤 것이 있는가? 오늘도 통신과 유저넷에는 질문들이 쏟아지고 있다. 그 질문의 대부분은 정말 기본적인 내용에 관한 것이다. "fsck는 어떻게 씁니까?", "mount가 무엇입니까?"... 이미 초보를 통과한 리눅서들에게는 황당하게 보이지만, 이런 질문을 하는 사용자들을 나무랄 수는 없다. 윈도우에 익숙한 사용자들에게 아무리 mount의 개념을 설명해도 알아듣지를 못하기 때문이다. 그래서 유닉스(리눅스)의 기본적인 개념이 없는 사용자는 모든 것이 난해하고 복잡해서 조금 용기를 내 보다가 중도하차하게 된다. 리눅서들에게는 형용모순처럼 보이는 질문을 하지 않을 수 없는 윈도우 사용자의 위치를 이해하기로 하자. 필자는 최근에 두 명의 윈도우 사용자에게 리눅스에 대해서 알려 주어야 할 일이 생겼다. 한 명은 윈도우 비쥬얼 프로그래밍을 7년 이상 해 온 개발자이고 다른 한 명은 윈도우 95/98에서 그래픽을 조금 해 본 초보 프로그래머이다. 이 들에게 어떻게 리눅스에 대해서 설명할 것인가? 이 둘을 만족 시킬 수 있는 한가지 설명 방식을 찾을 수 있을까? 
RTFM의 진정한 뜻
유저넷을 검색하다 보면 RTFM이라는 문장을 자주 만나게 될 것이다. AFAIK(As Far As I Know), IMHO(In My Humble Option), IIRC(If I Remember Correctly) 처럼 축약된 용어인데 이 말의 뜻을 알고 있는 독자들이 많을 것이다. 그 뜻은 "잘 정리된 설명서를 읽어라"(Read The Fine Manual)이다. 그런데 뉴스 그룹에서 보면 조금 이상한 문장 속에서 이 말이 나온다. 즉 "hey, shit! rtfm!!" 이런 방법으로 쓰이고 있는 것이다. 그 이유를 알아보자. 리눅스를 익히기 위해서 구할 수 있는 수많은 문서가 있다. 그러나 사용자의 대부분은 이런 설명서를 읽지 않는다. 영어가 모국어인 사람들도 이런 지경인데 한글을 쓰는 사용자들은 더 말할 필요가 없다. 이들은 뉴스그룹을 뒤지고 알고 싶은 것이 있으면 그냥 뉴스그룹에 포스팅한다. "이 것을 알려 주세요." 이런 뉴스 때문에 뉴스그룹의 토론이 제대로 이루어지지 않고 수많은 질문 글 사이에서 정보가치가 있는 글이 묻혀 버린다. 거의 대부분의 질문이 FAQ나 HOWTO 또는 LDP 문서에서 찾을 수 있음에도 오늘도 같은 질문이 계속되고 있다. 한 두번 이런 질문에 대해 친절히 대답을 알려 주던 리눅서들이 지치게 된다. 계속되는 질문에 응답하지 않게 되고 질문한 사람들은 왜 대답해주지 않느냐는 글을 올린다. 결국 화난 리눅서는 외칠 수 밖에 없다. rtfm!(read the FUCKING manual), rtfm의 진정한 뜻은 리눅서가 되고 싶으면 "설명서를 읽어라"라는 가장 기본적인 원칙을 무시하는 사용자들을 질타하는 목소리이다. 리눅서가 되고 싶은가? rtfm!!! 
어떤 것을 읽어야 하는가?
리눅서가 되려면 메뉴얼을 읽으라는 말을 듣고 그러고 싶어서 문서들을 뒤져보아도 아직 막막할 것이다. 설명들을 하나도 이해할 수 없고 이 책에서는 저 책을 참조하라고 하고 저 책은 다른 것을 참조하라고 하고 그 책은 다시... 초보자에게 메뉴얼을 읽으라는 말은 사전을 통채로 모두 읽으라는 말과 같이 들린다. 언제 사전을 모두 다 읽는단 말인가? 사전을 모두 읽는다고 그 언어를 자유자재로 구사할 수 있는가? 초보 리눅서들에게 필요한 것은 이런 메뉴얼을 관통하는 기본 원리에 대한 설명이다.
리눅스의 기본 원리는 무엇인가? 리눅스는 유닉스다. 그러므로 리눅스의 기본 원리는 유닉스의 기본 원리와 같다. 그렇다면 유닉스의 기본원리는 무엇인가? 그 것은 멀티유저 멀티타스킹 운영체제란 사실이다. 여기서 다시 지루한 유닉스의 특징을 나열하지는 않겠다. 유닉스 개론서 앞부분에 잘 정리되어 있는 내용을 읽어 볼 것. 멀티유저 시스템이란 사용자와 관리자란 계층이 있음을 뜻한다. 멀티유저 시스템을 유지하기 위해서는 관리자가 필요하다. 사용자들의 권한을 제어하고 서비스 해야 할 프로그램들을 정리하는 관리자는 유닉스에 대한 전반적 지식을 가진 사람이 할 수 있는 일이다. 과거 대부분의 유닉스 사용자들은 단말기 앞에서 자기 계정을 가지고 허락된 작업만을 할 수 있었다. 그 때는 유닉스 프로그램 설명서 정도만 가지고 있으면 유닉스를 쉽게 이해할 수 있었다. 복잡한 관리는 할 필요도 할 권한도 주어지지 않았기 때문에 그런 부분은 생각하지 않아도 되었기 때문이다. 그러나 PC에 직접 인스톨 할 수 있는 유닉스 클론들이 나타나면서 유닉스에 전혀 문외한인 사람들에게 유닉스 프로그램 사용부터 시스템 관리까지 모든 것을 한꺼번에 하도록 요구함으로써 아무 것도 할 수 없도록 만들어 버렸다. 리눅스가 더 어려워진 것이다. 
유닉스의 경험은 사용자 계정으로 로그인하여 cp,rm등의 명령을 익히는데서 부터 출발한다. 센드메일 설정등의 복잡한 일은 차후로 미루고 가장 기본적인 명령어들에 대한 이해를 먼저 시작하자. I&GSG와 LUG를 들고 ls, cp, vi 명령을 익히자. 시스템 관리는 지금 할 일이 아니다. I&GSG가 너무 단순하다면 유닉스 사용자 설명서를 한 권 구해서 읽으면서 설명되어 있는 프로그램을 직접 실행해 보는 것이 좋을 것이다. 요즘은 자신이 무슨 내용을 쓰고 있는지 확실히 알면서 쓴 책들이 많다. 유닉스 로그인, 셸에 대한 설명, 메뉴얼 페이지 사용법, 모든 명령어가 따르는 일반 형식, 네트웍 관련 사용자 프로그램들, 파이프와 필터, 파일의 처리, vi 사용법, 파일 시스템에 대한 이해, 유저넷과 뉴스그룹등등.. 유닉스 사용자 권한으로 할 수 있는 것이 많고 이 것을 제대로 익히면 시스템 관리도 어려운 것이 아니다. 
시스템 관리를 위해서는 LSAG가 필요하다. 이제 /etc 디렉토리를 관리해야 한다. 또한 리눅스 파일 시스템 표준(FSSTND)에 대한 이해를 해야 할 때이다. 모든 관리자용 프로그램은 /bin, /sbin, /usr/sbin, /usr/bin에 있고, 설정 파일은 /etc에, 로그는 /var/log에, 각 개인별 설정파일은 ~/.xxxrc 형태로 두는 것, 비표준 패키지는 /usr/local 아래에 인스톨 된다는 것, /var, /tmp, /usr, /etc, /lib 등의 디렉토리가 왜 만들어져 있고 어떻게 이용되는지 이해하게 될 것이다. 특정 프로그램이 실행되면서 어떤 파일을 참고하는지 알고 싶으면 다음과 같이 실행해 볼 것. 프로그램이 리눅스 시스템 안에서 어떤 함수를 호출하고 어떤 파일들을 열고 읽는지 한 눈에 볼 수 있다. 
# strace vi 2>a
# less a
파일 시스템 표준과 필터 프로그램에 대해 익히고 기본 에디터를 제대로 사용할 수 있다면 이제 설정 변경을 할 수 있다. /etc/hosts, /etc/exports 파일등을 다룰 수 있을 것이다. /etc 아래의 파일들은 메뉴얼 페이지가 있다. "man exports"라고 하면 그 파일의 형식을 자세히 보여 줄 것이다. 물론 이 파일이 어디에 쓰이는지는 파악을 해야 한다. 메뉴얼 등에서 이 파일이 쓰이는 곳을 찾아 보던지 "rpm -qf /etc/exports"라고 쳐서 이 파일이 어느 패키지에 속하는지 확인하고 그 패키지가 하는 일은 무엇인지 파악해도 된다. 많은 설정파일에 있듯이 "당신이 무슨 일을 하고 있는지 알지 못한다면 손대지 말것". 
이제 본격적으로 /etc/rc.d 아래의 파일을 손보자. 이 디렉토리에는 리눅스가 기동 되면서 필요한 작업을 하도록 되어 있는 곳이다. 지금 "ps axf"라고 실행해 보면 알 수 없는 프로그램들이 떠 있을 것이다. 쓰지도 않는 nfs, autofs, gpm등의 데몬이 떠 있다면 이들은 모두 /etc/rc.d/init.d 아래에서 찾을 수 있다. 어떤 데몬인지 확인하고 필요한지 여부를 판단한 다음 필요없다면 지워도 된다. 각 데몬들은 도스의 램상주 프로그램처럼 메모리를 낭비하고 있으므로 이 데몬들을 정리하면 컴퓨터의 반응이 훨씬 빨라질 것이다. 필자가 만난 한 유닉스 관리자는 인디고를 관리하고 있었는데 사용자가 컴퓨터가 잘 작동하지 않는다고 하면 6개짜리 인스톨 CD를 모두 재설치하는 것을 본 적이 있다. 256M의 메인메모리를 쓸데 없는 데몬이 모두 점유해서 정작 사용자가 띄운 그래픽 프로그램은 쓸 수 없을 정도로 느리게 실행되었다. 사용자는 컴퓨터가 후지다고 본체를 발로 차며 사용하고 있었다. /etc/rc.d/ 디렉토리를 마음대로 고칠 수 있다면 이제 스스로 리눅서라고 생각해도 좋다. 
웬만한 설정을 할 수 있고 감을 잡았다면 구체적 문제를 위해서 HOWTO 문서를 읽으면서튜닝을 하자. 백여개의 HOWTO 문서를 참고한다면 못할 일이 없다. 고정된 IP를 할당 받을 수 있다면 웹서버와 네임서버를 설치해서 사용해 보고 센드메일을 사용해서 메일을 내 컴퓨터에서 받아보기도 하자. 학생이라면 이제 프로그래밍에 눈을 돌릴 때이다. 커널부터 라이브러리 소스까지 가능하면 이들을 뒤져 볼 것. 버그를 발견했거나 성능을 향상시킬 방법을 알았다면 오픈소스 프로젝트에 참가해도 좋다. 
어떻게 읽어야 하는가?
다시 처음으로 돌아가자. 유닉스 개론서를 읽고 가이드를 보고 HOWTO를 보면 리눅서가 될 수 있다. 참 좋은 말이다. 그런데 여기에도 문제가 있다. 예를 들어 ipfwadm이라는 프로그램을 이용해서 IP-Masquerade를 하고 싶다. HOWTO 문서도 있지만 모든 것을 설명하고 있지는 않다. 그래서 스스로 "man ipfwadm"으로 사용법을 익히려고 한다. 알짜에는 한글로 된 메뉴얼 페이지가 나온다. 그러나 각각의 옵션에 대해서만 설명하고 있으며 이 설명도 잘 이해되지 않고 옵션들간의 연관관계에 대한 정확한 지침이 없다. IP-Masquerade mini HOWTO에는 다음과 같이 사용하라고 나와 있다. 
#ipfwadm -F -a m -S yyy.yyy.yyy.yyy/x -D 0.0.0.0/0
yyy..에서 출발한 패킷을 x로 마스크해서 문제가 없으면 모든 주소(-D)로 masquerade해서 보내라는 옵션이다. 그런데 메뉴얼페이지 어디에도 -a 다음에 m을 사용하는 이유를 설명해 놓지 않고 있다. 그러므로 ipfwadm을 사용해서 masquerade를 할 수 있다는 것을 알아내고 메뉴얼페이지를 아무리 읽어도 이 것을 할 수 없는 것이다. 이 문제를 어떻게 해결할 것인가? 마찬가지로 셸프로그래밍을 하면서 이 셸스크립트가 600초 후에는 스스로 끝내게 하는 기능을 넣고 싶다. 셸 스크립트 언어에는 전역변수로 SECONDS가 있다. 셸스크립트가 기동하면서 이 것을 0으로 초기화 시키면 그 때부터 1초마다 값이 증가한다. 이 값을 저장한 후에 나중에 비교해 보면 600초 후에 셸스크립트를 끝낼 수 있다. 그런데 bash 의 메뉴얼 페이지는 3960줄이다. 언제 이 설명서를 다 읽는단 말인가? 그리고 읽더라도 이 변수를 이런 용도로 사용할 수 있음을 어떻게 안단 말인가? bash 메뉴얼의 SECONDS 부분의 설명은 다음과 같다. 
SECONDS
Each time this parameter is referenced, the number of seconds since shell invocation is returned. If a value is assigned to SECONDS, the value returned upon subsequent references is the number of seconds since the assignment plus the value assigned. If SECONDS is unset, it loses its special properties, even if it is subsequently reset.
영어를 모국어로 사용하는 사람들도 이해하기 힘든 이런 설명을 보고 어떻게 이 변수의 용도를 짐작할 수 있을까? 그러므로 아무리 설명서를 읽어도 조금도 이해되지 않고 읽을 수록 머리만 복잡해질 뿐 리눅스를 사용하거나 관리하는데 도움이 되지 않는다. 셸프로그래밍에 대한 책도 나와 있지만 간단한 작업을 하기 위해 이런 책을 사서 읽는 다는 것은 낭비일 뿐이다. 셸프로그래밍 책을 보면 셸스크립트 언어만을 설명한 것이 아니라 필터 프로그램의 조합에 대한 설명이 더 많다. 또다시 필터 프로그램의 메뉴얼페이지를 읽어야 한다. 셸프로그래밍 책에서 셸스크립트의 한계를 지적하며 궁극적으로는 perl을 사용하라고 권한다. 공식 perl사이트인 http://www.perl.com에서 제공하는 perldoc 문서는 1256페이지에 달한다. perl 문서를 읽는다고 perl에 대해서 정통해 질 수 없다. perl로 짠 암호화 같은 스크립트 파일들은 그 내부를 들여다보고 한 줄 한 줄 분석해야 무슨 일을 하는지 알 수 있다. 원하는 일을 위해 perl로 스스로 프로그램을 짜는 것은 또다른 문제이다. 이렇게 얼키고 설켜있는 문서와 문서사이에서 중심을 잡고 개념을 파악하려면 어떻게 해야 할까?

• 중요 정보가 있는 곳을 기록해 놓자.  문서들을 읽는다고 모두 알 수는 없다. 읽을 때는 별 소용이 없어 보이지만 나중에 꼭 필요한 경우가 많다. 스스로 중요하다는 생각이 드는 내용이 있다면 표시해 놓거나 북마크에 넣어 두기 바란다. 유저넷에서 읽은 글이라면 다운 받아 저장해 놓거나 프린트 해두어도 된다. 흘러 지나간 정보에 대해서 KNOW WHERE를 기억할 수 있는 단서만 만들어 두면 나중에 쓸모 있는 정보가 된다. 기록해 놓지 못했지만 메뉴얼 페이지에서 본 기억이 있다면 find, grep 명령을 활용할 것.


• 중요한 것과 중요하지 않은 것을 구분하자. 프로그래밍을 위해서 프로그래밍 언어에 관심을 가지면 C가 유일하지만 홈페이지등에 쓰기 위한 CGI를 만들려면 사용할 수 있는 언어는 여러가지가 있다. perl, tcl, java, php3등등 각자 성능과 범용성, 다양한 라이브러리등으로 무장하고 우리를 유혹한다. 모두다 사용해 보고 싶은 욕심에 이것 저것 건들다 보면 아무 것도 할 수 없다. 언어는 나름의 장단점이 있으므로 한가지만을 선택해서 깊이 익히는 것이 낫다. 마찬가지로 리눅스 한글화, 커널 프로그래밍, 프로그램 포팅, 엑스윈도우 프로그래밍등등 모든 부분에 힘을 쏟을 수는 없다. 자기의 전공 분야를 만들고 여기에 집중할 필요가 있다. 메뉴얼 페이지를 볼 때도 ls 명령의 다양한 옵션을 모두 살펴볼 필요는 없다. HOWTO등에서 특별한 옵션을 사용해야만 필요한 일을 할 수 있도록 되어 있다면 모르지만 한 번 읽어 보는 정도로 그치고 이런 것에 신경을 쓸 필요는 없다. ls 명령은 -NFlai 정도만 알고 있어도 전혀 지장이 없다.


• HOWTO 등을 볼 때 옵션에 대해서 메뉴얼을 참고 하자. 가이드와 설명서에는 프로그램의 사용법만은 보여 준다. 그대로 따라만 해서는 언제나 실력이 그 상태에서 변하지 않는다. 응용을 할 수 없는 것이다. 설명서에 쓰이는 프로그램의 옵션 중에서 이해할 수 없는 것이 있다면 꼭 메뉴얼 페이지를 살펴볼 것. 위에서 말한 ipfwadm의 -a m 옵션은 메뉴얼에도 없으므로 원한다면 ipfwadm 프로그램 소스를 구해서 사용법을 알아 두는 것이 단순히 -a 다음에 m 을 쓰면 된다고 외우는 것보다 훨씬 도움이 된다. -a 다음에 쓸 수 있는 옵션이 m 뿐일까?


• 다른 사람의 글을 읽을 때 추가 정보에 주목하자.  유저넷이나 통신에서 다른 사람의 글을 읽을 때 꼭 질문/답변한 부분에만 관심을 가질 필요는 없다. 이런 글에서 나오는 프로그램 설명은 또다른 좋은 예가 되기 때문에 차분히 뜯어 볼 필요가 있다. 
  하이텔 linux 9번란 #19994 박종채 (누리단비)
  [답변] ls명령의 색깔지정=> .bashrc 1998-11-24 09:52 14 line
  ls명령어의 컬러 정의 지우기
  각자의 홈 디렉토리에 있는 .bashrc파일의 
  # alias 정의
  alias ls "ls -NF --color=auto"
  라고 되있는 부분을
  # alias 정의
  # alias ls "ls -NF --color=none"
  와 같이 막는다
  이 글은 통신에서 답변으로 올라온 글이다. ls 명령을 사용했을 때 파일명을 종류에 따라 다른 색으로 보이게 하는 방법에 대한 설명이다. 이 글을 읽고 .bashrc 파일을 고치기만 해서는 실력이 늘지 않는다. 여기서는 여러가지 정보를 가르쳐 주고 있다. .bashrc 파일이 왜 ls와 연관이 있는가? 이 파일이 하는 일은 무엇인가? alias 라는 명령은 무엇인가? ls의 -N, -F, --color=none 옵션이 각각 뜻하는 것은 무엇인가? 이런 것들을 생각하고 조사해 보아야 스스로 이 파일을 조작해서 pp라고 치면 "cd .." 명령이 수행되도록 만들고 이 것이 늘 그렇게 되도록 할 수 있게 된다. 메뉴얼페이지의 나열식 설명을 하나하나 읽는 것보다는 다른 사람의 글에서 프로그램의 활용예를 볼 때마다 이를 역으로 조사해 보는 것이 훨씬 효율이 좋다.


• 자기만의 방법을 사용하자.  모든 프로그램의 사용법을 알 수는 없다. /usr/bin 아래의 프로그램들을 보면 모르는 것이 대부분이다. 많은 것들이 필터 역할을 하는 프로그램들이다. 셸스크립트의 필터로 사용할 목적으로 이 것들을 모두 알고 있을 필요는 없다. sed, awk, grep, cut, find 등 대표적인 것들만 조사해 보자. 그리고 이들도 서로 사용법이 겹친다. 그러므로 한가지 프로그램을 확실히 사용할 줄 알면 다른 것들을 몰라도 버틸 수 있다. perl을 알고 있다면 이들 필터까지도 무시해도 된다. /usr/src/linux 아래에서 SCSI_LUN 이라는 문자를 가진 파일을 알아보고 싶다면 어떻게 할 수 있을까? 필자는 아래처럼 한다. 
  /usr/src/linux# grep "SCSI_LUN" *.[ch] */*.[ch] */*/*.[ch] 
  멋있고 세련된 방법을 들라면 다음과 같이 할 수 있을 것이다. 
  /usr/src/linux# grep "SCSI_LUN" `find . -name "*.[ch]" -print `
  물론 위의 find 정도는 알고 있어야 하겠지만 몰라도 상관없다. grep 하나로 버틸 수 있으니까. 자신만의 방법이 있다면 이 것을 버리지 말것. 복잡한 프로그램의 사용법을 열심히 익혀도 정작 필요할 때에는 생각이 나지 않고 틀리게 쓸 경우가 많기 때문에 그렇게 쓸 수 있다는 것을 알고만 있으면 된다. 유닉스의 기본 원칙은 "작고 단순한 것이 아름다운 것"이다.


• 목표를 가지자. 운영체계 수집을 취미로 하는 사람들이 있다. 몇 기가씩 되는 하드 디스크를 여러 개 붙이고 여러 운영체계를 깔아 놓고 쓰는 사람들이 많다. 생산적인 일을 하거나 운영체계 공부를 하는 것이 아니라 그 자체가 취미인 사람들이다. 이런 사람들에게는 리눅스가 별 필요가 없고 도움도 되지 않는다. 윈도우가 마음에 들지 않는다면 요즘 뜨고 있는 BeOS나 깔아서 쓰는 것이 좋을 것이다. 현장에서 지금 웹서버를 돌려야 하는 사람이라면 당연히 취사선택할 부분이 눈에 들어오겠지만 이제 리눅스에 대해서 관심을 가진 시간있는 사람들은 어떤 것을 먼저 해야할지 막막할 뿐일 것이다. 필자는 10년 전 PC에서 엑스윈도우를 돌리고 싶다는 생각에 유닉스를 구하러 다녔다. BSD 계열과 SYSV 계열의 여러 유닉스를 인스톨 했지만 모두 실패하고 리눅스를 만나서 소원을 이룰 수 있었다. 남들에게 쓸모 없어 보이는 생각을 품고 있거나 황당해 보이는 목표를 가지고 덤벼들어도 상관없다. 그 목표를 위해서 리눅스를 뒤지다 보면 어느 새 리눅스 해커가 되어 있는 자신을 발견할 수 있을 것이다.

결국에는 스스로 해야 한다.
리눅서가 되기 위해서 읽어야 할 문서와 그런 문서를 읽는 방법과 자세에 대해서 설명 했다. 웬만한 일은 훑어 본 문서를 다시 참고하면 해결할 수있다. 그러나 정작 필요한 부분에서는 문서들이 크게 도움을 주지 않는다. 박스기사에 예를 든 eql에 대한 것도 유저넷에 질문만 넘쳐 날 뿐 쓸만한 답변은 없다. 혼자서 eql을 세팅할 수 있었다고 해도 크게 쓸모가 없다. 왜냐하면 결정적으로 eql 디바이스가 한 개만 제공된다는 것이다. 전용선 업체에서 여러 가입자에게 서비스 할 수 없는 일에 신경을 쓸 이유가 없기 때문에 실제로 사용해 보기는 힘들 것이다. 전용선 업체에서 이 기능을 사용하여 가입자 수를 늘이고 싶으면 커널 디바이스 드라이버를 고쳐야 한다. drivers/net/eql.c를 고치면 되지만 누가 해 주겠는가? 당신 밖에 없다. 외국에서는 이미 사장된 디바이스가 되었기 때문에 아무도 손을 대지 않을 것이다. 이 것을 고쳐서 동작하게만 한다면 경쟁업체보다 훨씬 기술적 우위를 점할 수 있으니까 한 번 도전해 보기 바란다. 리눅스는 이렇게 스스로 하는 사람들이 만들어 왔다. 커널-메일링-리스트 FAQ에 보면 아직 만들어지지 않은 디바이스 드라이버를 어떻게 만들어야 하는가에 대한 답변이 있다. 
질문 : TW-345C(가상의 디바이스)를 위한 드라이버를 만들려면 어떻게 시작하나요? 
답변 : 우선 하드웨어 명세서를 구하라. 본사에 요청을 했을 때 명세서를 주기를 거부한다면 대리점등에 요청하라. 대리점은 아무 생각없이 명세서를 주는 경우가 많다. 대리점에서 명세서를 넘겨 받았으면 그 사람의 이름은 비밀에 부쳐라. 어디에서도 명세를 구하지 못했다면 윈도우/도스 디바이스 드라이버를 역엔지니어링하라. 많은 정보를 얻을 수 있을 것이다. 드라이버가 어떤 방식으로 하드웨어를 접근하는지 알 수 없으면 dosemu 위에서 실행해 보라. log에 많은 정보가 쌓일 것이다. 
문서에 없다고 포기하면 안된다. 방법을 몰라도 포기하지 말것. 커널 디바이스는 여태까지 이런 비참한 방법으로 만들어져 왔다. 해결해야할 문제를 위해서는 스스로 나서야 한다. 아무리 힘들어도 가능성만 있다면 도전해야 하고 리눅스가 자라는 바탕이 바로 그 것이다. 
리눅서가 되자.
필자가 본 리눅서들은 거의 해커기질이 있었다. 윈도우에서 자주 사용하는 프로그램의 기능을 고쳐쓰거나 스스로 만들어 쓰는 프로그램을 가지고 있었다. 그런 프로그램의 질을 따질 필요는 없다. 컴퓨터를 만지면서 문제의식을 가지고 스스로 해결해보고자 하는 자세가 중요하다. 리눅스 박스를 만들고 도전해 보자. 문제를 자신이 해결할 수 있기까지 얼마나 걸릴까? 리눅스만 하루 종일 한다면 2년 정도면 될 것이다. 조급하게 생각하지 말 것. 여유를 가지고 도전하자. 오픈소스 공동체에 참가하여 리눅스를 즐기다보면 어느새 시간이 지나고 당신은 실력있는 리눅서가 되어 있을 것이다. 
리눅서는 어떻게 크는가? 현상태에 안주하지 않고 스스로 문제의식을 가지며, 업체에서 기능을 추가해 줄 때까지 기다리지 않고 자신이 기능을 추가하며, 다른 리눅서가 만든 문서를 완전히 소화하고 스스로 또 하나의 문서를 만들어 내며, 불가능해 보이는 것을 현실로 만들어내면서 큰다.