Linux 세계의 연금술

Linux 권위자인 H. Peter Anvin은 최근에 오래된 시스템의 용도를 파일 서버로 변경했다. 그는 잦은 보안 업데이트, RPM 기반 패키지 관리 시스템 및 서버에 적절하게 패키지로 제공되는 소프트웨어의 수를 근거로 하여 Fedora를 운영 체제로 선택했다. Anvin의 시스템은 RAID(Redundant Array of Independent Disks) 6 구성에서 9TB의 새 하드 디스크를 호스트한다. 책상 아래에 사용하지 않은 채 방치하고 있었던 이전의 개발 시스템이 지금은 매우 중요한 작업을 수행하고 있다.

이 시스템이 아주 오래된 것은 아니지만, 컴퓨터 하드웨어를 사용하지 않고 있었다는 것은 대체로 뭔가 문제가 있음을 나타낸다. 이런 시스템은 오늘날과 같은 빠른 발전과 변화의 추세를 따라잡기에는 대체로 너무 느리고 이를 지원하기에 너무 오래된 것은 물론이고, 특히 보증 기간이 지난 경우 기술적으로 안정적이지 않다. 하지만, 시스템이 오래되었다고 그냥 버리기에는 너무 아깝다. 많은 회사와 가정에서는 이렇게 오래된 시스템을 학교나 도서관에 기증하여 더 오래 사용할 수 있도록 하고 있지만, 이런 시스템을 기증받아 사용하는 사람들 역시 그런 구형 시스템으로 뭘 할 수 있을지 몰라서 결국 하드웨어가 재활용 센터로 넘어가는 운명에 처하는 경우가 많다. 이는 자원 낭비일 뿐 아니라, 때로는 재활용 컴퓨터가 소위 제3세계 국가의 쓰레기 매립장이나 소각로로 보내지는 바람에, 전자 폐기물이라는 새로운 문제를 만들어낸다(자세한 내용은 참고자료 참조).

본 기사에서는 Linux 운영 체제를 사용하여 오래되긴 했지만 작동하는 컴퓨터 시스템의 용도를 변경함으로써, 구식 시스템에 서버, 미디어 플레이어 또는 씬 클라이언트로서의 새로운 생명을 불어넣는 방법을 설명한다.

위로

용도 변경을 위한 단계적 절차

용도 변경 프로세스는 표면적으로는 다른 Linux 변환 프로세스, 즉 시스템에 Linux를 설치하는 프로세스와 상당히 같은 모습으로 나타난다. 특히, 최근의 배포 버전에서는 이 프로세스가 충분히 간단한 것으로 보이지만, 자세히 들여다보면 그렇지도 않다. 어떤 시스템에 어떤 Linux를 설치해야 할까 하는 문제가 있는 것이다.

다음 다섯 단계를 따르는 것이 좋다.

1. 프로젝트의 요구사항을 결정한다.

   의욕에 넘치는 많은 시스템 빌더들이 이 단계를 건너뛰곤 하지만, 어쩌면 이 단계가 가장 중요한 단계일 수 있다. 자신이 원하는 것이 무엇인지 정확히 모른다면 작업의 완료 여부를 결정하기 어려울 것이다. 아래의 프로젝트 요구사항 결정 섹션에 세 프로젝트에 대한 지침이 있다.

2. 하드웨어의 적합성을 평가한다.

   이 단계는 간단해 보이며, 실제로도 그렇다. 프로젝트 요구사항을 현재 보유하고 있는 하드웨어와 비교한다. 이때 적합한 소프트웨어를 찾을 수 있을 것이라 가정한다. 여기서 언급하는 프로젝트들에 대한 검사 목록뿐 아니라 유용한 힌트는 하드웨어 평가를 참조한다.

3. 프로젝트에 적당한 소프트웨어를 결정한다.

   최소한 필자 입장에서는 이 부분이 참 재미있게 느껴진다. 이전 데스크탑 또는 랩탑 하드웨어의 경우, 실제로 같은 모델의 하드웨어를 사용하는 사람들이 수없이 많이 있고 이들에 의해 하드웨어 드라이버 지원이 유지 관리되므로, 거의 항상 Linux가 그 해답이다. 어떤 배포 버전이 해당 프로젝트에 가장 알맞은지 조사해본다(지침은 아래의 적절한 Linux 배포 버전 결정 참조). 어떤 하드웨어에 적합한 드라이버를 찾으려면 꽤 많은 노력이 필요할 수도 있다.

4. 소프트웨어를 찾아서 수집한 후 설치 및 구성한다.

   프로젝트를 가동하여 실행한다. Linux를 설치하려면 보통 CD 이미지를 다운로드하고 이를 디스크에 레코딩한 후 프로젝트 시스템에 있는 이미지에서 부팅하기만 하면 되므로 그리 어렵지 않다. 설치 관리자의 지시사항에 따르면 되고, 몇 가지 미리 알림 메시지에 대해서는 찾기, 수집 및 구현을 참조하고 그대로 진행하면 된다.

5. 시스템을 유지 관리한다.

   백업은 당연히 중요하다. 특히 오래된 시스템을 사용할 때는 하드웨어 문제에 각별히 주의해야 한다.

위로

프로젝트 요구사항 결정

우선, 프로젝트를 선택하여 정의한다. 요구사항이 아래에 나열한 것과 꼭 일치하지 않아도 된다. 여기서 핵심은 자신의 요구사항에 대해 사용 가능한 하드웨어를 판단할 수 있는 기준이 될 것인지 생각해야 한다는 점이다.

파일 서버 프로젝트 요구사항

파일 서버 프로젝트의 일반적인 요구사항은 다음과 같다.

• 시스템은 안정적이어야 하지만 꼭 빠를 필요는 없다.
• 이 시스템이 백업 서버의 역할을 할 수도 있으므로, 하드 디스크의 용량이 제법 크고 가능하다면 새 것으로 사용하는 것이 중요하다. RAID를 사용하는 것이 좋을 수 있으므로, RAID를 지원하는 마더보드가 있어야 할 것이다.
• 네트워킹 지원은 필수 사항이다.
• 이 시스템에는 모니터나 스피커 따위가 아예 없을 수도 있으므로 그래픽 및 오디오 지원은 불필요하다.
• 특히 시스템에 모니터나 키보드가 없는 경우에는 원격 유지 관리를 위해 VNC(Virtual Network Computing) 지원이 필수 사항이다.

미디어 플레이어 프로젝트 요구사항

미디어 플레이어는 사용자가 가진 모든 음악, 7.1 오디오를 포함한 홈시어터 및 디지털 프로젝터 또는 간단한 침실용 동영상 플레이어를 가진 헤드리스 주크 박스(즉, 모니터나 키보드가 없음)일 수 있다. (이전 랩탑으로 훌륭한 침실용 미디어 플레이어를 만들 수 있음) 이 섹션에서는 요구사항에 대해 생각하는 방법에 관한 몇 가지 아이디어를 제시한다.

• 시스템은 동영상을 올바로 재생할 수 있을 만큼은 빨라야 한다.
• 하드 디스크는 일정량의 미디어 데이터를 저장할 수 있을 만큼 충분히 커야 한다.
• 시스템에서 동영상을 재생할 경우, 그래픽 인터페이스에서 사용자가 보유한 모니터 또는 텔레비전을 지원해야 한다. 이는 모니터의 요구사항에 따라 S-video에서 HDMI까지 어떤 것이든 될 수 있다. 그래픽 카드에서 지원하는 해상도도 확인한다.
• 오디오 인터페이스는 사용자의 앰프 및 스피커 설치 환경을 지원해야 한다. 단순히 헤드폰이나 값싼 컴퓨터 스피커를 포함한 침실용 시스템으로 구성하는 경우에는 마더보드의 표준 헤드폰 플러그나 랩탑의 내장 스피커를 사용할 수도 있다. 홈시어터로 구성하려면 시스템에 고급 사운드 카드가 있어야 하며, 보통 그렇게 비싸지는 않다.
• 다운로드를 위해서는 네트워킹 지원이 필수적이지만, 재생만 할 경우에는 그렇지 않다.
• CD 및/또는 DVD를 재생하려면 CD/DVD 드라이브가 있어야 한다.
• 원격 제어를 위해서는 원격 및 적외선 인터페이스가 필요하다.

씬 클라이언트 프로젝트 요구사항

일반적으로 다음 두 가지 유형의 시스템을 씬 클라이언트라고 한다.

• 전용 씬 클라이언트. 이런 클라이언트는 로컬 처리 작업을 수행하지 않지만, 애플리케이션뿐 아니라 데스크탑 서비스를 제공하는 더 큰 서버에 연결된다.
• 독립형 씬 클라이언트. 이런 시스템은 씬 클라이언트로 사용되는 완벽히 운영되는 시스템이다. 데스크탑 서비스는 로컬로 제공되지만, 애플리케이션과 보통은 데이터 역시 다른 곳에서 호스트된다. 최근에는 휴대폰에도 데스크탑 환경과 여러 가지 애플리케이션이 지원되므로, 이런 시스템이 훨씬 더 보편적으로 사용되는 추세다. 이것은 로컬 시스템에서 연산 처리를 위해 더 큰 원격 서버를 사용하는 클라우드 컴퓨팅을 위한 표준 구성이다. (자세한 내용은 참고자료를 참조한다.)

시스템 요구사항은 사용되는 씬 클라이언트의 유형에 따라 다소 다르다. 매우 오래되고 속도가 느린 시스템은 전용 씬 클라이언트로 사용하고, 중간 등급의 시스템은 어느 쪽으로도 사용할 수 있다. 일부 작고 가벼운 Linux 배포 버전에서는 매우 오래되었거나 느리거나 자원이 제한적이거나 이런 약점들이 조합된 시스템일지라도 독립형 클라이언트만큼 충분히 빠르게 작동할 수 있다.

• 시스템은 그래픽을 구동할 수 있을 만큼 충분히 빨라야 하며, 독립형 클라이언트의 경우에는 최소 운영 체제 및 창 관리자를 실행할 수 있을 정도로 빨라야 한다.
• 네트워킹은 필수 사항이다.
• 전용 씬 클라이언트의 경우, 로컬 네트워크에 서버가 필요하다. 그런 서버의 설치는 본 기사에서 다루는 주제의 범위를 벗어나는 내용이지만, 꼭 Linux가 아니더라도 선택이 폭이 넓다.
• 독립형 씬 클라이언트의 경우, 로컬 네트워크 상의 서버가 꼭 필요한 것은 아니지만 사용할 수는 있다. 또한, 이 시스템을 클라우드 컴퓨팅 시스템으로 사용하여 웹 브라우저를 통해 정보에 액세스할 수도 있다. 호텔과 안내 센터가 종종 이런 방식으로 설치된다.
• 하드 디스크가 꼭 필요하지는 않지만, 하드 디스크를 사용하여 운영 체제를 호스트할 수 있다.

위로

하드웨어 평가

다음으로, 용도 변경을 생각 중인 시스템을 편견에 찬 시선으로 바라보자. 일부 시스템은 용도 변경을 생각조차 할 수 없다는 것이 사실이다. 따라서 해당 시스템에 오류가 있는 컴포넌트가 없는지 확인해야 하고, 특히 마더보드와 같은 컴포넌트에 이상이 있으면 불가피하게 전체 시스템을 사용하지 못할 수 있으므로 반드시 확인한다. 의문 사항이 있는 경우 부적합한 후보 식별을 참조한다.

시스템 문제점을 진단하고 종종 수정까지 하기 위해 가장 유용한 소프트웨어 도구는 이번에도 다행히 Linux를 기반으로 하는 Ultimate 부트 CD이다. 이 한 장의 CD에 무료로 사용 가능한 다양한 하드 디스크 및 네트워크 도구가 들어 있고(이들 도구 중 다수를 하드웨어 제조업체에서 제공함), 이 모든 것을 한데 모아 두었으므로 빠르게 부팅할 수 있는 프론트엔드에서 손쉽게 액세스할 수 있다. 링크는 참고 자료를 참조한다.

프로젝트에 필요한 모든 컴포넌트가 시스템에 있는지 확인한다. 표 1은 각 프로젝트에 대한 일반 지침을 나타낸 것이다. 하지만, 이런 지침에 얽매여 상상의 나래를 옭아매지는 말자. 예를 들어, 라우터와 방화벽으로 모두 작동할 파일 서버를 원한다면 최소한 두 개의 네트워크 어댑터가 필요할 것이다. 하나는 근거리 통신망(LAN)용, 다른 하나는 광역 네트워크(WAN)용이다.

많은 씬 클라이언트에서 그렇듯이, 프로젝트에서 하드 디스크가 불필요한 경우에는 CD, USB 또는 PXE(Preboot eXecution Environment, 즉 네트워크 부트)를 통해 부팅해야 한다. 분명한 것은, 해당 부팅 방법을 하드웨어에서도 지원해야 한다는 점이며, 이는 CD에서 부팅하기 위한 CD/ROM 드라이브, USB 키와 USB를 통해 부팅하기 위한 마더보드 지원 및 PXE를 통해 부팅하기 위한 로컬 시스템 서버를 의미한다. 보통은 부트 설정에서 시스템의 기본 입/출력(I/O) 시스템(BIOS)을 살펴보거나 해당 매뉴얼을 확인하여 지원되는 부트 방식을 결정할 수 있다.

또한, 프로젝트에서 고급 그래픽이나 오디오가 요구되는 경우에는 하드웨어가 큰 문제가 될 수 있다는 점에도 유의하자. 상황이 서서히 변하고는 있지만, 지금까지는 ATI 카드보다 제조업체에서 훨씬 더 NVIDIA 그래픽 카드를 훌륭하게 지원해왔다. 오디오의 경우, 기본 Linux 커널 사운드 드라이버가 다양한 장치를 지원하지만, 특히 장치가 마더보드에 내장되어 있는 경우 장치를 잘 연구해야 한다.

마지막으로, 제조업체에서 프로젝트 시스템을 기본 빌드하는 경우에는 linux라는 키워드와 함께 시스템의 부품 번호로 인터넷을 검색해본다. 예를 들어, Lenovo ThinkPad T43에서 작동하는 Linux에 관한 정보를 찾으려면 thinkpad t43 linux를 검색해본다. 그 시스템에서 Linux를 작동시키는 데 필요한 구체적이고 실질적인 정보뿐 아니라, 수많은 기술 데이터를 찾을 수 있을 것이다.

위로

적당한 Linux 배포 버전 결정

각종 배포 버전은 손쉽게 다운로드하여 LiveCD 또는 USB 플래시 드라이브(UFD)에서 사용할 수 있으므로, 알맞은 Linux 배포 버전을 조사하는 최선의 방법은 아마 시행착오 방법일 것이다. 하지만, 1차 조사는 각 배포 버전에 대한 정보와 실제 사례를 수집하는 웹 사이트인 DistroWatch에서 시작해야 한다(링크는 참고자료 참조). 아래의 주에 소개하는 내용은 엄격한 권장사항이 아니라 지침 정도라고 생각해야 한다. 최선의 방법은 역시 조사와 실험일 뿐이다.

파일 및 인쇄 서버

서버 구성에서 가장 중요한 운영 체제 고려사항은 유지 관리의 용이성이다. 운영 체제를 설치한 후에는 사용자가 따로 작업하지 않아도 계속 올바로 설치된 상태를 유지하기를 바랄 것이다. 배포 버전에는 네트워크 서비스를 위해 내장된 지원 기능, 특히 다른 운영 체제(예: Windows®)와의 인터페이스 기능이 있어야 하고 프린터, 네트워크 카드 및 기타 하드웨어를 위한 다양한 드라이버도 있어야 한다.

이런 요구사항을 충족하는 배포 버전에는 Ubuntu Server Edition, CentOS, Fedora 및 OpenSUSE가 포함된다. 명령행에서 이들 사이에 가장 뚜렷한 차이점은 패키지 관리이다. Ubuntu와 OpenSUSE에서는 aptitude를 사용하는 반면, Fedora와 CentOS에서는 RPM 기반 도구를 사용하기 때문이다. 서버에 표준 패키지 요구사항 이외의 특정 요구사항이 있는 경우, 각 배포 버전에 대해 지원되는 패키지 목록을 살펴보는 합당하다. 하지만, 특히 최근의 데스크탑 또는 서버 에디션 Linux 배포 버전에는 모두 네트워크 지원, 다른 시스템과의 파일 공유를 위한 Samba 지원, 다양한 하드웨어 드라이버 및 고급 패키지 관리 기능이 있으므로, 완벽히 온전한 서버의 기능을 수행할 수 있다.

미디어 플레이어 프로젝트 요구사항

미디어 플레이어의 경우, 가장 중요한 운영 체제 고려사항은 하드웨어 지원이다. 정확히 어떤 오디오 및 비디오 하드웨어를 보유하고 있는지 찾고, linux라는 키워드로 이런 하드웨어를 인터넷에서 검색하여 다른 사용자들의 경험을 살펴보고 배우자.

그 다음, 애플리케이션에 대해 생각한다. 대부분의 배포 버전에는 종류는 다를 수 있지만 미디어 플레이어가 함께 제공된다. 오디오, 비디오, 사진 슬라이드 쇼, TV 튜닝 또는 이들을 임의로 조합한 형태 중 어떤 것을 원하느냐에 따라 선택할 수 있는 애플리케이션이 많이 있다. 이들을 모두 하나로 연결하기 위한 한 가지 훌륭한 플랫폼이 바로 무료 디지털 비디오 레코더(DVR)로서 자체 과금하는 MythTV이며, 실제로는 훨씬 더 많은 역할을 하고 활발한 개발자 커뮤니티가 있다. MythTV는 대부분의 주요 배포 버전에서 지원되지만, Fedora와 Ubuntu에서 특히 진가를 발휘한다. MythTV가 미리 패키지화되어 제공되는 배포 버전도 있으며, 이를 간편하게 각각 MythDora 및 Mythbuntu라고 부른다. OpenSUSE 역시 많이 사용된다.

마지막으로, Linux는 DVD 재생을 지원하지 않기로 유명하다. 그런데 이는 대부분의 Linux 배포 버전에서 사용자가 DVD 재생 기능을 사용하려면 Linux 설치 후 추가 단계를 수행해야 한다는 점에서만 사실이다. 이에 대해서는 복잡한 법률적 이유가 있지만, 간단히 말하자면 DVD 코덱은 특허 기술이지만 Linux 자체는 라이센스가 오픈 소스 형태로 무료로 제공된다고 설명할 수 있다. 위에서 말한 추가 단계는 꽤 간단하며 대개는 소유권이 따로 있는 코덱과 라이브러리를 설치하는 작업이다.

씬 클라이언트 프로젝트 요구사항

씬 클라이언트는 일반적으로 자원의 제약을 받는다. 그렇지 않을 때도, 씬 클라이언트를 사용하는 취지는 클라이언트의 운영 체제가 사라지거나, 최소한 지나치게 드러나지 않으면서도 빠르게 작동하도록 하기 위한 것이다. (데스크탑 서비스를 포함한 모든 기능을 위해 서버에 따라 다른) 전용 씬 클라이언트에 이상적인 운영 체제는 표준 씬 클라이언트 통신 프로토콜, 특히 Citrix 및 RDP(Windows 터미널 서비스)를 지원하는 운영 체제이다. 작고 가벼운 수많은 Linux 배포 버전은 씬 클라이언트 전용으로 디자인된 여러 가지 요구사항을 포함한 요구사항을 만족시킨다.

Thinstation이 바로 그런 배포 버전 중 하나이다. Thinstation은 씬 클라이언트용으로 현재 사용되는 수많은 연결 프로토콜을 지원한다. 전용 씬 클라이언트와 독립형 시스템에 모두 Thinstation을 사용할 수 있다. Puppy Linux를 사용하는 것도 가능하다. Puppy는 Xfce를 창 관리자로 사용하는 매우 작은 배포 버전이다. Puppy는 씬 클라이언트로 사용되는 독립형 시스템에 가장 적합하다. 이런 배포 버전에 대한 링크는 참고자료를 참조한다.

위로

찾기, 수집 및 구현

우리 조상들은 생활에 필요한 자원을 찾아서 수집하는 데 대부분의 여가 시간을 썼다. 그러나 우리가 진행하려는 프로젝트에서는 단순히 사용자가 선택한 Linux 배포 버전을 다운로드하고, 프로젝트 시스템에서 부팅하고, 특정 프로젝트에 필요한 추가 패키지 또는 지원 기능으로 Linux를 구성하기만 하면 된다. (아마 말할 필요도 없는 일이겠지만, 이런 프로젝트에서는 모두 프로젝트 시스템이 철저히 정리되었고 데이터는 다른 곳에 백업된 것으로 가정한다.)

1. 최신의 대상 배포 버전을 다운로드하여 CD에 레코딩한다.
2. CD를 넣고 시스템을 부팅한다.

   CD에서 부팅하려면 BIOS 설정을 변경해야 할 수도 있다. 자동 설치 지시사항을 따른다.

3. 시스템이 다시 부팅되고 설치를 완료한 후, 원하는 방법으로 부팅하도록 시스템을 설정한다.

   서버의 경우, 사용 가능한 하드 드라이브에서 간단히 부팅하고 싶을 것이다. 하지만, 미디어 플레이어나 씬 클라이언트의 경우에는 CD나 UFD에서 또는 네트워크를 통해 부팅할 수 있다.

4. 앞서 제시한 요구사항을 충족시키도록 시스템과 애플리케이션을 설정한다.

   시스템 설정을 조사한다. 앞에서 생각해두었던 모든 프로젝트 요구사항을 염두에 두고 원하는 일을 수행할 수 있도록 시스템을 설정한다. 예를 들어, 서버가 파일 공유를 시작하는 데 있어 콘솔에 로그온하는 사람에 좌우되면 안 된다. 가정용 미디어 플레이어는 MythTV 기본 화면이나 사용자가 선택한 애플리케이션으로 바로 부팅해야 한다. 여러 사람이 사용하는 씬 클라이언트라면 로그인 화면으로 부팅되어야 할 것이다.

5. 공개하여 누구든 사용할 수 있게 하려는 내부 디스크가 있는 경우, Samba를 사용하여 공유한다.

   자세한 내용은 Samba 문서뿐 아니라 Linux 파일 공유에 대해 설명하는 다른 developerWorks 기사도 참조한다. CUPS를 사용하면 Samba를 통해 프린터를 공유할 수 있다. 각 공유 프린터가 설치되어 있는지 확인한 다음, Samba 도구를 사용하여 공유한다(Linux 인쇄에 관한 튜토리얼은 참고자료를 참조함).

6. 헤드리스 시스템의 경우, 시스템에 원격으로 로그인할 수 있도록 VNC 및/또는 sshd를 설치하고 구성해야 한다. 특히 Ubuntu와 같은 일부 시스템에서는 이를 원격 데스크탑이라고 한다.

위로

부적합한 후보 식별

모든 프로젝트 후보가 적합하지는 않을 것이라는 점을 유념하자. 중요 컴포넌트가 문제가 되는 것으로 파악되는 경우, 그 시스템은 다른 프로젝트, 파트 시스템 또는 단순히 노후화된 시스템을 처분한다는 목적에 더 알맞을 수도 있다. 물론, 전자 폐기물과 관련된 중요한 문제를 염두에 두어야 한다.

하드 디스크, 팬 및 전원 공급 장치는 실제로 움직이는 컴퓨터 부품이므로, 교체해야 할 필요성이 가장 큰 부품이다. 다행히도, 이런 부품은 모두 비교적 비싸지 않으므로, 이런 부품을 문제점으로 식별한다고 해서 프로젝트가 끝나는 것은 아니다. 메모리는 조금 더 비싸지만, 역시 전체 프로젝트를 포기하지 않고 새 것으로 바꾸거나 업그레이드할 수도 있다.

하지만, 프로세서 자체 또는 마더보드가 불량인 경우에는 시스템을 재활용할 가치가 없을 수 있다. 구형 마더보드는 찾기 어려울 수 있고, 일단 마더보드 업그레이드를 시작하면 반드시 그에 맞는 새 프로세서, 다른 메모리 모듈, 새 그래픽 카드는 물론이고, 어쩌면 새 하드 디스크도 필요할 것이다. 그래서 마치 결국에는 새 손잡이 세 개와 새 해머 머리 두 개만 덜렁 가지게 된 아둔한 목수의 낡아빠진 해머처럼, 이런저런 부품을 모두 바꾸는 바람에 결국 재활용의 효과를 그다지 보지 못하는 시스템이 되고 말 것이다.

위로

결론

전자 폐기물을 재활용하여 훌륭하게 용도 변경하는 것은 비용을 절약하고, 사용하는 다른 시스템에 더욱 알맞은 시스템으로 바꾸고, 가장 중요한 점으로서 시스템에 포함된 독성 물질과 실현되지 않은 시스템의 잠재력이 쓰레기 매립장이나 소각로에서 그 생을 허무하게 마감하지 않도록 하기 위한 멋진 방법이다. Linux의 다양한 기능 덕분에 그 프로세스가 더욱 흥미로워진다. My developerWorks의 Green computing group에 참가하여 프로젝트 진행 상황을 알려주기 바란다.

참고자료

교육

• Jeffrey의 "Linux thin clients and cloud computing"(developerWorks, 2009년 4월) 기사를 읽어보면 Linux와 클라우드가 어떻게 친환경적인 조합을 제공하는지 알 수 있다.
  
  
• Gentoo Technologies 사장이 쓴 "Samba 2.2"(developerWorks, 2001년 4월) 기사에 Samba 파일 공유에 대해 잘 소개되어 있다.
  
  
• "게으른 리눅스: 시스템 관리자를 위한 열 가지 트릭"(developerWorks, 2008년 7월)에서 시스템 관리자를 위한 훌륭한 팁을 알아보자. 특히, 트릭 6: SSH 터널을 통한 원격 VNC 세션을 눈여겨 읽어보자.
  
  
• Wikipedia에서 전자 폐기물(electronic waste 또는 e-waste에 대해 알아보자.
  
  
• "리눅스 부팅 프로세스 연구"(developerWorks, 2006년 5월)는 developerWorks의 베테랑 기고가인 M. Tim Jones가 Linux 부팅 프로세스에 관한 빼어난 기사이다.
  
  
• "LPI exam 102 prep, Topic 107: Printing"(developerWorks, 2006년 8월)에서는 Samba를 통한 방법을 포함하여, Linux 환경에서의 인쇄 설정 방법을 보여준다.
  
  
• developerWorks Linux 영역에서는 Linux 개발자에게 도움이 되는 여러 가지 리소스를 제공하고 있으며 가장 인기 있는 기사와 튜토리얼도 볼 수 있다.
  
  
• developerWorks에 있는 Linux 팁과 Linux 튜토리얼을 모두 볼 수 있다.
  
  
• developerWorks 기술 행사 및 웹 캐스트를 통해 최신 정보를 얻을 수 있다.
  
  

제품 및 기술

• DistroWatch 웹 사이트는 각 Linux 배포 버전에 대한 자세한 정보와 실제 사례를 제공하는 훌륭한 소스이다.
  
  
• Ubuntu는 데스크탑에 적합한 전체 배포 버전이다. 서버에 대해서는 Ubuntu Server Edition을, 미디어 플레이어에 대해서는 Mythbuntu를 확인해야 한다.
  
  
• Fedora와 CentOS는 Red Hat을 기반으로 하는 배포 버전으로서, 둘 다 파일 서버를 위한 훌륭한 플랫폼이다. 미디어 플레이어의 경우 MythDora도 확인한다.
  
  
• OpenSUSE는 파일 서버용으로 매우 적합한 또 다른 우수한 데스크탑 배포 버전이다.
  
  
• Thinstation은 Linux 씬 클라이언트용으로 특별히 디자인된 배포 버전이다.
  
  
• Puppy Linux는 씬 클라이언트에 적합하게 가벼운 Linux 배포 버전이다.
  
  
• Ultimate Boot CD는 무료로 제공되는 Linux 기반 시스템 관리 도구 콜렉션이다.
  
  
• developerWorks에서 직접 다운로드할 수 있는 IBM 시험판 소프트웨어를 사용하여 Linux와 관련된 후속 개발 프로젝트를 구현해 볼 수 있다.
  
  

토론

• My developerWorks의 Green computing group에 참가하여 오래된 하드웨어의 용도 변경에 관련된 경험을 공유하자.
  
  
• 사용자의 개인 프로파일과 사용자 정의 홈 페이지가 제공되는 My developerWorks community에서는 관심을 가지고 있는 developerWorks의 여러 주제를 추적할 수 있으며 다른 developerWorks 사용자들과 의견을 나눌 수도 있다.
  
  

필자소개

Jeffrey Osier-Mixon은 기술 작가, 오픈 소스 옹호자 겸 커뮤니티 관리자이다. 그는 오픈 소스 소프트웨어에 대한 블로그에 많은 글을 게시하고 Meld 임베디드 Linux 커뮤니티를 운영 중이며, Linux 컨퍼런스에서 활발히 연설하고 있다.

아티클 순위

의견

위로

목차

• Linux 세계의 연금술
• 용도 변경을 위한 단계적 절차
• 프로젝트 요구사항 결정
• 하드웨어 평가
• 적당한 Linux 배포 버전 결정
• 찾기, 수집 및 구현
• 부적합한 후보 식별
• 결론
• 참고자료
• 필자소개
• 의견