Gentoo 리눅스의 허와 실

지리즈의 이미지

자신의 PC에 최적화된 운영체제를 사용할 수 있다는 것은 매우 매력적인 일이다. 하지만, 이에 대한 대가(컴파일)가 만만하지 않다는 것은 실제로 설치를 해보면 뼈저리게 느낀다. 이 컴파일 때문에 하루나 이틀정도 컴퓨터를 사용할 수 없게 될 때마다 매번 다음에는 다른 배포본으로 넘어가자 하면서 결심하지만, 여전히 시스템을 재설치하게 될 경우 Gentoo 라이브CD를 찾게 하는 미묘한 매력이 있다.

Gentoo 리눅스가 가지는 다른 리눅스 배포본들과의 차이는 그 시스템 혹은 특정한 어플리케이션에 최적화될 수 있도록 자동적으로 빌드(컴파일)되면서 설치된다는 점이다. 하지만, 이러한 최적화라는 단어가 사용자들에게 어떠한 이득을 줄 것인지에 대해서는 사실 과장된 면이나 혹은 과소평가된 점이 없지 않아 있다.

이 글은 데스크탑 OS로서 Gentoo 리눅스에 대해서 관심을 가지는 사람들에게 그들이 자신의 기존의 운영체제 대신에 설치할 운영체제로서 Gentoo 리눅스를 선택하는데 간단한 소개서 역할을 하기를 바라는 마음에 작성한다.

최적화 그것은 환상 1. CFLAG

Gentoo에서 최적화란 많은 의미가 있지만 가장 처음 출발선은 자신의 CPU에 알맞은 GCC의 컴파일 옵션(CFLAG)으로 시스템을 빌드하는 것이다. 이론적으로는 범용(i386)보다는 이득이 있어야 한다. 물론 벤치마킹을 해보면 차이도 날 것이다. 본인 같은 경우 오로지 Gentoo를 위해(사실은 Football Manager라는 게임을 위해 ㅠ.ㅠ) 듀얼코어 CPU에 램2G 시스템을 장만했다. 빌드타임에서 상당한 이득을 볼 수 있을 것이라는 기대 때문이다. 그런데, 아이러니컬하게도 이러한 시스템일수록 CPU 최적화의 이득은 거의 없다. 빠른 클럭속도나 멀티테스킹 성능이 최적화로 인한 다른 배포본과의 차이를 매우 근소한 것으로 만들어 버리기 때문이다. 오직 빌드타임에만 이득을 볼 뿐이다. 더 비극적인 사실은 비싼 돈을 들여 장만한 이 시스템의 최대 성능을 사용하기 위해서 내가 할 수 있는 일이라곤 오직 Gentoo를 빌드하는 것 뿐이라는 것이다.

하지만, 자신의 시스템이 상당한 구형이라면 어떠할까? 이를테면 CPU 클럭 속도가 200~500MHz 수준에 램 256M 이하 정도를 말하는 것이다. 이럴 경우 확실히 최적화의 이득이 커진다. 물론 시스템 전반이 마치 자신의 성능의 2~3 이상으로 향상되는 듯한 비약적인 이득은 없다. 하지만, 부분적으로 작은 규모의 연산이 매우 빠른 속도로 발생하는 어플리케이션을 사용한다면 확연히 차이가 난다. 이를테면 Mplayer에서 매우 압축률이 높은 동영상을 재생해 보면 느끼게 될 것이다.

최적화 그것은 환상 2. USE

Gentoo에 있어서 최적화의 또 다른 의미는 시스템을 매우 간결하게 구축할 수 있다는 것이다. 만약 내가 프린트기능을 사용하지 않거나 혹은 Gnome은 전혀 사용하지 않고 KDE만을 사용한다던가 하면 불필요한 기능에 대해서는 완전히 제거한 상태로 설치가 가능하고 전체 시스템을 아주 작은 용량으로 유지하는 것이 가능하다. 또한 라이브러리의 크기가 절약됨으로 메모리 사용량도 적어지고 성능향상을 도모할 수도 있다.

그런데, 사실 특정한 어플리케이션 한두가지를 위해 리눅스를 사용하지 않는다면, 이러한 것도 그다지 의미가 없다. KDE와 Gnome의 Killer App이 각각 있기 마련이고, KDE사용자이건 Gnome 사용자이건 서로의 어플리케이션을 전혀 사용하지 않기란 어렵기 때문이다. 또한 아주 가끔 한두번 사용하는 기능도 사실 데스크탑으로서 그 기능이 없으면 여간해서는 불편하기 마련이다. 즉, 특정한 기회가 발생할 때, 이러한 것을 포함하지 않고 시스템을 빌드했다가는 꽤나 골치 아픈 경험을 하게 될 가능성이 높다. 경우에 따라서는 많은 리눅스 사용자들이 그러하듯 마치 윈도우 OS처럼 다른 배포본을 별도의 파티션에 설치해서 듀얼부팅하거나 가상화 프로그램으로 돌려가면서 사용하게 될 수도 있다.

그렇지만, 반드시 이것이 환상인 것만은 아니다.
자신이 매우 노련한 Gentoo 유저라면 자주 사용하지는 않지만 꼭 필요한 것들을 미리 포함시켜 시스템을 빌드할 수 있거나 혹은 스스로 몇몇 어플리케이션에 대해서 포기한다면 이러한 문제로부터 해방될 수도 있다.

역시 CFLAG때와 마찬가지로 자신이 사용하고자 하는 시스템이 매우 열악하고, 주로 사용하는 것이 아닌 보조적이 목적으로 사용한다면, 여기서 다시 한번 Gentoo가 위력을 발휘한다. 본인 같은 경우 아주 낡은 노트북 한대를 듀얼 혹은 트리플 모니터 대용으로 사용하고 있다. Gentoo가 아니면 이 노트북의 쾌적한 사용은 꿈도 꾸지 못할 일이다.

빌드의 압박

서두에서도 말했지만, 빌드의 압박이라는 것은 매우 괴로운 일이다. 기본설정에서 실수 또는 근시안적인 생각으로 인해 시스템이 원하지 않은 방향으로 구축되었을 경우, 이를 만회하기 위해 상당한 분량의 시스템을 다시 빌드해야 한다면, 울고 싶은 생각마저 들기도 한다.

하지만, 반드시 소스로부터 빌드해 나간다는 것이 최적화를 제외하고도 꼭 얻을 것이 없는 것만은 아니다. 기본적으로 라이센스와 관련된 부분에서 매우 유연하기 때문이다. 즉, 소스를 스스로 다운로드 받아서 설치하는 것이기 때문에 법적으로 더 자유로울 수 있으며 따라서 Gentoo는 다른 어떠한 배포본보다 더 유연하고 일관적인 설치를 제공할 수 있다. 이를테면, 상업용 소스 또한 유저가 다운 받아서 특정 위치에 넣기만 한다면 다른 여느 어플리케이션처럼 설치가 가능하고, 제거도 가능하다. 아니면, 자바 같은 경우도 그냥 설치가 가능하다. 이러한 보다 넓은 법적인 자유로움은 초급, 중급자에게는 매우 매력적인 일일 것이다.

Gentoo는 중급자 이상을 위한 선택?

사용자를 구분하는 것은 모호한 일일 것이다.
일단 이곳에서는 그 분류를 크게 두가지로 나누어야 할 것 같다.
하나는 시스템 자체를 사용하는 목적이고, 다른 하나는 시스템 자체에 대한 지식일 것이다.

시스템 자체를 그냥 평범한 범주(인터넷,문서작성, 동영상 감상,게임)을 목적으로 사용한다면, 초급,중급,고급사용자 모두에게 적절한 선택이 될 수 있다. 즉, 시스템 자체에 대한 이해가 없어도 부딪히게 되는 문제가 거의 없기 때문이다.

시스템 자체를 중급 이상 즉 연구, 네트워크 감시와 같은 일반적인 데스크탑 유저가 하지 않는 목적으로 사용할 경우는 시스템에 대한 이해가 중급수준이라면 귀찮은 문제에 처하게 될 수도 있다. 다른 배포본에서는 하드디스크 공간과 메모리만 낭비하는 쓰레기처럼 불필요하게 많다고 여겨지던 기능들을 사용하게 될 가능성이 높기 때문이고, 관련된 설정에 대한 지식이 부족할 경우 Gentoo에서 정상적인 동작을 하게 만들기가 쉽지 않기 때문이다. 만약, 자신이 중급이상의 목적으로 시스템을 사용할 것이고, 시스템 이해도가 중급자 수준이라면 다른 배포본을 사용하라고 권장하고 싶다. 상급자라면 스스로 문제를 잘 해결해 나갈 수 있기 때문에 어느 배포본이던 중요하지 않을 것이다.

Gentoo는 얼리어댑터를 위한 시스템?

beryl이나 composite같은 선망의 대상이 되는 기능들이 있다. 물론 지금에는 대부분의 배포본이 기본으로 포함하는 것들이지만, 이들이 막 세상에 알려졌을 때는 이것을 설치하여 사용하는 얼리어댑터들은 그렇지 않은 이들의 선망의 대상이 되고는 했다.

Gentoo가 소스에서 빌드하기 때문에 사람들이 종종 가지는 오해가 Gentoo는 얼리어댑터들에게 매우 좋은 시스템일 것이라는 점이다. 사실 i386시스템을 사용한다면 일부는 맞다. 하지만, Gentoo는 아주 다양한 환경에서 문제없이 자신들이 배포하는 소스가 빌드되어야 하기 때문에 실제로는 제한적인 환경에서 전문가들에게 의해 빌드 되어진 바이너리가 배포가 되는 다른 배포본보다 오히려 안정버전이 느리게 나온다. 만약 x86-64 시스템 사용자라면 더 비극적이다.

내가 볼 때는 Gentoo는 보수적인 배포본이다. 아니, 보수적으로 사용할수록 Gentoo는 더욱 그 가치가 커진다. 다른 배포본들은 특정한 기능을 사용하기 위해서 그것에 연관된 의존성 등의 문제 때문에 배포본 자체를 업그래이드해야 하는 일이 발생하기도 한다. Gentoo는 이러한 면에서는 매우 유연하다. 만약 유저가 능력이 매우 좋다면, 레드헷 6.2와 같은 커널 및 라이브러리에 beryl을 사용하는 일도 가능하다. 이 과장된 예가 주는 의미는 자신이 익숙한 환경에서 큰 변화없이 새로운 기능을 사용할 수 있다는 것이고, 이는 곳 유저가 보수적일수록 Gentoo로 인한 이득이 더 커진다는 것을 의미한다.

수동으로 작성해야 하는 설정파일 불편하다. 하지만…

Gentoo는 많은 설정파일을 직접 에디터를 이용해서 작성해 주어야 한다. 다른 배포본들이 GUI기반의 자동화툴을 가지고 있는 것에 비하면 Gentoo는 꽤나 하드코어하다고 할 만도 하다. Gentoo가 초심자들에게 어렵다는 것도 이러한 것에서 출발할 것이다.

하지만, 설정파일을 수동을 작성하는 것에 익숙해진다면, 이것이 매우 분명하다고 신뢰할 수 있는 방법이라는 것을 깨닫게 된다. GUI툴들은 영리하지 못하다. GUI툴로서 설정을 작성하는 것의 범주는 GUI를 제공하는 기능에 제한적이고, 만약 예외가 발생할 경우 신뢰할 수 없는 결과를 초래하기도 한다. 특히 일부의 기능을 위해서 직접 설정파일을 수정했을 경우, GUI가 이 설정을 삭제하기도 하고, 아니면 GUI가 제공하는 설정과 충돌해서 시스템이 정상적으로 동작하지 못하는 경우가 생길 수 있다. Gentoo는 오직 이 설정파일을 수정하는 것은 유저뿐이며 이러한 것이 매우 신뢰할 수 있는 시스템 관리 방법이라는 것은 분명하다.
물론 다른 배포본에서도 오직 GUI에서 제공하는 기능만에 만족하고 GUI만으로 사용한다면, 역시 이들 또한 신뢰할 수 있다. 하지만, 배포본이 판이 바뀔 때마다 빈번히 바뀔 수 있는 GUI를 붙잡고 씨름하는 것도 사실 골치 아픈 일이다.

안정성

정확히 자신이 가진 지식과 비례한다고 말하긴 어렵다. 초심자들은 분명 Gentoo 가이드북을 충실히 따를 것이고, 문제에 처할 경우도 드물다. 선무당이 사람잡는다고 했는가? 시스템에 대한 이해가 어중간한 수준의 사용자가 과욕을 부릴 경우 상당히 괴로운 처지에 처할 수 있다.

분명 시스템에 대한 높은 수준의 이해를 가지고 있다면 가장 안정적인 배포본이라 확신하다. 특히 자신이 가지고 있는 시스템이 다른 배포본에서 문제가 발생한다면 Gentoo는 좋은 선택이 될 수 있다. 물론 자신이 이미 상당한 경험자라면 상관없지만, 그렇지 않다면 많은 공부가 필요할 것이다.

보안

보안이 목적이라면 상급자가 아니면 피해야 한다. 만약, 자신이 리눅스의 보안관련 지식이 해박하다면 다른 배포본보다 더 튼튼하게 구축할 수도 있다. 하지만, 보안은 최고수준의 지식이 아니면 의미가 없다. 따라서, 자신이 어중간한 수준의 보안 지식을 가지고 있다면 함부로 서버용도로 Gentoo를 사용하지 말기를 권장하고 싶다.

사용관련 팁

위에도 언급된 바가 있지만, 얼리어댑터적인 성격으로 Gentoo를 사용하지 않는 편이 더 낫다. 한번 설치를 하면 큰 변화없이 시스템을 꾸준히 이용하기를 원하는 사용자들에게 좋다. 따라서 업그레이드에 대한 개념 또한 다른 배포본 들하고는 다르게 접근할 필요성이 있다. Gentoo는 라이브CD버전은 있지만, Gentoo자체의 버전은 없다.(있나? 없을 것이다.) 자신이 Gentoo 저장소에서 스냅샷을 받아온 시점이 당신이 사용하는 Gentoo의 고정된 배포본이다. 소소한 업그레이드가 나왔다고 매번 시스템을 다시 빌드하는 낭비는 피해라. 가능하면, 스냅샷 받아온 것을 중심으로 최적화하는 바에 대해서 고민하는 것이 더 바람직한 일이라 생각한다. 아주 큰 변화가 있는 시점 이를 테면 gcc가 3.4에서 4.0으로 바뀌었다던가 아니면 KDE가 4.0이 나왔다던가 하는 시점에서 차라리 전체를 재설치하는 편이 더 낫다.

Gentoo의 설치는 아주 특이한데, 기생환경(?)에서 설치가 가능하다. 다른 배포본들은 설치라는 과정에 시스템이 모두 완전히 장악된 상태가 되지만, Gentoo는 다른 리눅스 운영체제가 운영되는 상태하에서 설치할 수 있다는 의미다. 이를 효과적으로 이용하면 빌드의 압박에서 조금이나마 벗어날 수 있다.

이를 이용하는 방법 중에 하나가 이중으로 시스템을 구성하는 것이다. 즉, 윈도우 리눅스 멀티 부팅처럼, 다른 리눅스 배포본+Gentoo 혹은 Gentoo+Gentoo로 구성하면 좋다. 다른 일을 하면서 빌드를 하면, 그 동안 시스템을 사용하지 못하는 일을 피할 수 있기 때문이다. 물론 빌드시간이 더 소요가 되기는 한다. 개인적으로는 Gentoo+Gentoo를 권장한다. Swap 파티션말고 추가적으로 /usr/portage 디렉토리를 공유할 수 있음으로 용량도 절약되고, 새로 빌드된 시스템이 문제가 없는지 미리 확인할 수 있기 때문이다.

기생설치(?)를 이용하는 다른 하나는 성능이 아주 떨어지는 시스템과 매우 좋은 시스템을 가지고 있을 경우에, 성능이 아주 떨어지는 시스템을 위해서 매우 좋은 시스템에서 Gentoo를 빌드하는 것으로 시간을 절약하는 것이다. 이기종(이를 테면 x86과 x86-64)사이에서도 충분히 가능하며 이에 관련된 팁을 Gentoo 홈페이지에서 찾을 수 있다.

마무리

가능한 Gentoo의 지식을 모르는 사람도 쉽게 이해할 수 있도록 Gentoo적인 내용은 피했다. 이 문서는 어디까지나 데스크탑 OS로서 Gentoo를 선택하려는 사람들에 위해 작성된 소개서이지 설치관련 도움문서는 아니기 때문이다.

다른 배포본들도 마찬가지겠지만, Gentoo 역시 매우 좋은 배포본이고, 옳바른 용도로 그것을 활용하면, 당신의 매우 좋은 도우미가 될 수 있으리라 믿는다.

Forza Gentoo!

댓글

권순선의 이미지

글 잘 읽었습니다. 부디 건전한 flame이 많이 일어나기를 바랍니다. :-)

지리즈의 이미지

이글도 사실 반성문입니다. ;-)

There is no spoon. Neo from the Matrix 1999.

There is no spoon. Neo from the Matrix 1999.

warpdory의 이미지

제가 젠투를 안 쓰는 이유와 흡사하군요.

같은 시스템에서 나름대로 최적화 시켰다고 생각했던 젠투와 ... 무겁다고들 하는 RHEL 을 깔아놓고 시뮬레이션 돌리니깐 3% 이하의 성능 차이가 나오더군요. 굳이 그렇게까지 시간 들여가며 '최적화' 라고 불리우는 걸 할 생각이 있을까 ... 싶은 생각이 들어서 그냥 CentOS 깔고 시뮬레이션 돌리고 있습니다.

개인적으로는 .. glibc 꼬임 현상 때문에 250 기가 파티션이 훨훨 날라가 버린 이후에는 젠투를 안 쓰고 있습니다.. T.T

---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도

즐겁게 놀아보자.
http://akpil.egloos.com


---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도

즐겁게 놀아보자.

지리즈의 이미지

중급+중급 유저라
많은 어려움을 겪고 있습니다.

그럼에도 불구하고, 대안이 없네요.

Fedora의 KDE 지원은 썩 마음에 들지 않고,
Kubuntu(debian 계열)은 너무 달라서 적응이 안되고...

There is no spoon. Neo from the Matrix 1999.

There is no spoon. Neo from the Matrix 1999.

송효진의 이미지

데스크탑이라면 우분투 쓰라면 쓸 수는 있을것 같습니다.
하지만 서버는 젠투 외에는 생각도 못하고 있습니다.

CFLAGS 부터 해서
아파치의 -DDEFAULT_SERVER_LIMIT
php 의 안쓰는 모듈 비활성화
rc 레벨의 간소화
안쓰는 커널 모듈 해제 및 주요 모듈 커널에 포함 등등

이만큼 내 맘대로 하면서 배포판 정책을 유지할 수 있는 리눅스는 젠투밖에 없죠.
특히 패치파일을 ebuild 에 살짝 넣어 빌드할 수 있다는게 굉장한 매력입니다.
배포판에서 각종 패치들을 적용하여 안정적이고 편리하게 패키징한 프로그램을
소스 열어서 직접 패치한다는건 갑갑한 일이죠.

그리고, 젠투의 패키지 안정버전이 나오는 속도가
타 배포판에 비해 느린 이유중 가장 큰건 인력의 부재라고 생각되어 집니다.
특히 우분투와 비교하면 자금력부터 하늘과 땅 차이 라고 느껴지네요.

emerge money
http://wiki.kldp.org/wiki.php/GentooInstallSimple - 명령어도 몇개 안되요~

김정균의 이미지

흠.. 이 글은 서버에서 사용하는 배포본과 S.E 의 입장에서 적은 글입니다. 써 놓고 보니 주제가 좀 명확해야 겠다는 생각이 들어서 머릿글을 남깁니다. 송 효진님의 글에 대한 반박이 아닙니다. ^^; 물론 전혀 관계가 없는 것은 아니지만..
---

흠 다른 배포본은 왜 그렇게 관리가 안된다고 생각하시는지요? 뭐 글쓰신 의도야 효진님에게는 젠투가 제일 스타일에 맞는것 같다는 것을 나타내고 싶지만, 글의 뉘앙스는 젠투가 객관적으로 가장 낫다라고 주장하는 듯이 보입니다.

다른 배포본을 사용하는 사람들이 주장하는 바에 동의가 되지 않는 점입니다. 차라리 rpm packaging + Yum repositary 구성보다 편하다라고 주장하는게 맞지 않을까 생각됩니다만..

제가 서버에서의 RHEL style 을 고집하는 이유는..

1. 인력 구하기가 쉽다.
2. 제일 익숙하다.

입니다. 대부분의 RHEL 은 이게 구려.. 하고선 그래서 나는 이 배포본을 사용해.. 라고 주장을 하는 것에 대해서 저는 RHEL 로 그 이상을 구축해서 사용하고 있기 때문에 동의가 안되는 거죠.

또한 최적화라는 단어에 대해서, 얼마나 최적화를 잘 할 수 있을지 모르겠습니다. -O2 대신에 -O3 가 들어가야 한다든지.. 또는 -g3 가 들어가면 안된다든지.. 최적화에 대한 잘못된 인식이 더 팽배하거든요. 과연 compiler 에 대한 이해를 하고선 최적화라는 말을 사용하는지도 의문입니다. 그냥 문서에서 그러하니 이렇게 하는 사람들이 대부분일테니까요.

ebuild 와 같은 시스템은 어느 배포본이나 다 있습니다. 다만 다른 배포본들은 굳이 빌드를 하지 않아도 되기 때문에 알 필요가 없어서 모르고 있을 수도 있다는 것이 차이일 뿐이죠. 다량의 서버를 관리하자면 configure, make, make install 의 과정을 거치기는 힙듭니다. 즉 한대에서 빌드를 해서 여러대에 배포를 하는 방식을 사용해야 합니다. 이런 점에서 각 시스템의 패키징 시스템은 SE 로서는 익혀야할 필수 있습니다. 이것이 가능하다면 어떠한 배포본에서도 효진님이 주장하시는 바는 가능합니다. 오히려 Zentoo 의 단점은 각 시스템에 대하여 최적화를 내세우기 때문에 몇천대의 서버가 사양이 제각가이라면 이는 장점이 아니라 단점이 될 수가 있기 때문입니다.

그렇다고 해서 Zentoo 를 REDHAT 같이 관리를 할 수 없느냐도 아닙니다. 다만 인식의 전환을 하지 못하기 때문에 못한다고 생각할 수 있는 것이고, Zentoo 의 장점을 부각하시는 분들은 다른 배포본에서의 인식의 전환을 고려하지 않기 때문에 Zentoo 가 최고인것 처럼 보이는 거죠.

다만, 젠투의 라이브러리 정책의 유연함은 인정해 드리고 싶습니다. 다른 배포본들이 가지고 있지 못한 장점이죠. :-)

솔직히 Zentoo 가 최고야.. ubuntu 가 최고야.. 이런 signature 는 좀 안봤으면 좋겠습니다. 좋아하는 것을 홍보하는 것이 아니라 종교를 전파하기 위한 전도같이 보입니다. 임예진님 사진이 signature 에 있는 것과 별 다름이 없어 보이거든요 --;

OS 를 선택함에 있어서는 관리하는 주체가 가장 잘 숙지하고 있는 OS (배포본)을 선택하는 것이 맞다고 생각이 됩니다. 다만, 회사에 매여있는 입장에서는 내가 영원히 할 것이 아니라면 그 OS(배포본) 에 대하여 깊숙히 잘 알고 있는 후임을 쉽게 뽑을 수 있는 배포본을 선택하는 것이 회사나 당사자에게 이득이라고 생각이 됩니다.

다만, 아쉬운 것은 이런것을 생각하는 회사는 정말 드물다는 것이죠.

일례로 제가 다니는 회사에서는 2000여대의 서버가 FreeBSD 가 주류였습니다. 현재는 Linux 로 모두 migration 이 되었습니다. migration 이 된 이유는 단 한가지였습니다. FreeBSD 를 유지보수할 사람이 없어졌기 때문이죠. 물론 저도 BSD 시스템을 관리했었고 유지했었습니다만.. 그당시에는 OS 에 대한 키를 다른 분이 맡고 있었기 때문입니다. 그리고 현재 잘 돌아가고 성능도 나쁘지 않은 OS 를 변경할 이유도 제가 없었습니다. 하지만, 키가 제게 넘어오면서 FreeBSD 는 짐이 되고 맙니다. 제가 가장 잘 아는 것은 RHEL 시스템이었으니까요. 2000 여대의 FreeBSD 서버를 Linux 로 migration 하는 작업은 생각보다 쉽지 않습니다. 다른 팀과의 일정 조율도 필요하고, 그 OS 상에서 돌아가는 application 의 migration 도 필요하기 때문에, 거의 2년이라는 시간이 걸렸습니다. 즉 회사로서도 저로서도 2년이라는 시간을 소비한 격이 되는 겁니다. 저는 FreeBSD 의 키를 가지고 있는 사람을 잡고, FreeBSD 를 유지하는 입장이었지만, 당사자와 회사의 입장은 조금 달랐나 봅니다.

사실, OS 의 선택은 시선에 따라 다를 수 있습니다. 쉽게 보면 쉬운 작업이고 어렵게 보면 어려운 작업입니다. 저의 경우에는 대략 6명분의 업무를 혼자 맡게 되다보니, 이를 배분하는 작업까지, 그리고 신입을 뽑아서 인수인계를 해야 하는 부분까지 생각을 하다 보니, 어렵게 생각할 수 밖에 없더군요.

저 역시 RHEL 이 최고라고 생각하지 않습니다. 제일 익숙한 RHEL 에서도 불만이 있어서 AnNyung 이라는 배포본을 fork 를 했으니까요. 하지만 이 AnNyung 을 사용하라고 권장하지도 않습니다. 그 업무를 제가 다 떠 맡아야 할 수 있으니까요.

다만, 제가 조언을 해 드리고 싶은 것은, 배포본이 중요한 것이 아니라 시스템이 중요한 것이라는 겁니다. 즉, FreeBSD 의 키를 가진 사람이 없어지더라도 그 사람의 존재감이 없더라도 잘 운영이 되고 잘 돌아갈 수 있는 시스템을 구축해야 한다는 것 입니다. 이런점은 어느 배포본에서도 제공해 줄 수가 없습니다. 그리고 이런일을 System Engineer 가 해야할 일이라는 겁니다. configure/make/make install 을 S.E 가 해야할 주 임무가 아니라는 것이죠. 이제는 "최적화"라는 단어에서 해방이 되기를 바랍니다.

송효진의 이미지

최적화도 최적화지만 그 최적화에 많은 노력이 들지 않는 유연함을 강조하고 싶네요.
한번 해 놓으면 버전업때도 특별한 노력 없이 적용할 수 있는 유연함이요.

보안결함이 없는 프로그램은 흔치 않고 언제나 보안결함이 있을 수 있다는 생각으로 관리하고 있습니다.
때문에 대몬이 뜨는 류의 프로그램들은 안정버전이 나오면 무조건 업데이트를 합니다.
그래서 내가 해 놓은 설정을 유지하는것이 가장 귀찮은 작업이었습니다.
(이 귀찮은 작업에 유일한 것이 php 입니다. 강력하고 좋은것이지만 보안에 관해서는 완전불신 입니다.)

시스템이 중요하다는 것에는 동의합니다.
다른 배포판에서도 소스기반으로 받아서 설치가 가능하다는 것도 압니다.
그러나 매번 받아서 패치하고 설치해야 하는것으로 알고 있습니다.

우분투 라이브 시디를 젠투 설치에 이용하는 요즘에는
우분투라면 꽤 편리할 수도 있겠다는 생각을 하는데,
적어도 커널과 몇몇 패키지는 소스기반의 패키지관리가 되어야 해서
시도를 안해봤습니다.

일이 많다보니 후임에 대한 생각보다는 당장의 내 일을 빨리 처리하는것을 생각합니다.
전에는 바이너리 기반에서 안되면 '또 내가 컴파일 해야 하나' 하며 한숨이 나왔는데,
젠투로 넘어오면서 간단하게 처리되었을 뿐만 아니라,
못했던것들까지 간단히 다 처리하였습니다.
따라하기 류의 문서를 보며 낑낑대던 초보였는데,
단숨에 고수가 된것 같은 기분이었습니다.
설치에 있어서 가장 제 시간을 뺏지 않는 배포판은 젠투가 유일합니다.
(컴파일 하는 시간은 기다리지 않고 다른 일을 합니다.)

어느 누가 운영해도 잘 돌아가도록 하는건 문서화 밖에 답이 없다고 생각됩니다.
배포판 정책 내에서 간단히 설치하고 사용하는 서버라도,
오래 쓰다보면 자신만의 규칙 같은게 생기고,
그 규칙이 시스템에 꽤 중요한 자리를 차지할 수도 있겠지요.

말이 정리가 안되는것 같은데,
대충 끝맺자면
저는 이것저것 설정 많이 합니다. 그래서 젠투가 유일한 해답입니다.

어느누가 설치를 해도 거의 같은 결과가 나오는 fix 된 안정화 솔루션이 필요하다면
안녕이 가장 강력한 해답입니다.

emerge money
http://wiki.kldp.org/wiki.php/GentooInstallSimple - 명령어도 몇개 안되요~

지리즈의 이미지

확실히 Gentoo가 엔터프라이즈 환경에서 제약이 발생하는 것은 사실입니다.
저도 납품하는 OS는 RHEL 계열을 이용합니다.
가장 보편적이기 때문에, 어쩔 수 없는 선택입니다.

하지만, 아주 약간 너그럽게 펼친다면 debian계열보다는 Gentoo가 "RHEL 시스템"에 더 비슷합니다.
유지보수라는 것은 확연하게 다르지만, 운용이라는 면에서는 그렇다는 의미입니다.

그리고,유지보수라는 것이 생각보다 RHEL 시스템에 비해 인력자체는 더 적게 듭니다.
물론 빌드에 걸리는 부분이 있지만, 이 시간동안 인력이 지켜볼 필요도 없고,
비슷한 시스템(적어도 서버라면 CPU계열만 같다면)이라면 한대에서 빌드하고,
바이너리 상태에서 주변 시스템에 배포도 가능합니다.
젠투는 기본적으로 Rsync 배포를 사용합니다. rsync의 유연함과 신속함이 운영체제 전반에 녹아있죠.

만약 CPU가 다르더라도 기본설정 파일 한두개만 해당 시스템에서 수정하고,
emerge world 해버리면 끝납니다.

최적화에 대한 단어에서 해방되라고 말씀하시지만,
사실 서버에서의 최적화는 성능의 향상보다는 보안과의 싸움입니다.
불필요한 패키지 설치로 인해서 보안에 관련된 시스템 유지 보수에 비용이 증가할 가능성이 있습니다.
Gentoo는 확실히 이러한 타배포본을 바닐라로 설치하는 것보다는 더 적은 필요한 패키지만을 설치가 가능합니다.
따라서, 장기적인 운영에서 보안결함이 발생할 확률이 더 적어지게 되죠.

보안 목적이 아니라도 S.E.가 컴파일을 해야 하는 경우가 반드시 필요한 것이 있습니다.
WAS가 오라클 DB와 연동되어야 한다던가, 특정한 미들웨어와의 연동이 필요한다던가 하는 식으로 말이죠.
즉, 최적화가 아니라 그 시스템의 용도에 따르는 특화라고 해야 겠죠.
이러한 것이 확실히 타 배포본보다 ebuild가 매우 유연하게 대응할 수 있습니다.

configure/make/make install 을 S.E 가 해야할 주 임무가 아니라는 지적,
이것이 사실상 젠투의 ebuild가 존재하는 이유라고 생각합니다.
ebuild 자체가 이러한 다소 번거로운 소프트웨어 설치과정을
정책화 및 은폐화하고, 일관성있게 유지시켜주며 간결하고 신뢰할 수 있도록 해주기 때문입니다.

만약, 초기 정책결정자가 충실히 이러한 것에 대해서 준비하고, 문서화만한 해놓는다면,
제가 볼때는 RHEL에 대안적인 선택으로서 Gentoo 또한 괜찮은 배포본이라고 보여 집니다.

결국 TOC나 향후 유지,관리, 인력 확충이라는 부분에 있어서 Gentoo가
국내여건에서 그렇게 까지 낮은 평가를 받을 필요는 없을 것 같습니다.

There is no spoon. Neo from the Matrix 1999

There is no spoon. Neo from the Matrix 1999.

dalgarak의 이미지

버전에 대한 구별이 거의 없지만, deprecated된 프로파일을 새 프로파일로 고쳐주기위해 make.profile의 symlink를 변경해주는 일은 있지요. (필요할 때 친절하게 안내메시지도 뜨고...)

profile/USE flag에 대한 올바른 이해를 가지는데 걸리는 진입장벽은 여전히 문제거리를 쥐고 있습니다. 개인적으로, 설치 가이드를 충실하게 지키려는 분들은 봤지만 처음부터 USE 플래그에 대한 올바른 이해를 가지고 시작하시는 분은 거의 못봤습니다. :)

app-portage/profuse와 같이 손쉽게 USE flag를 선별할 수 있는 좋은 툴들이 있지만, 부트스트랩을 위해 존재하는 internal용 플래그 역시 밖으로 노출되고 있기 때문에 첫 사용자에게는 혼란이 생길 수 밖에 없습니다. 툴도 알고 대충의 구조도 알지만 이 플래그가 뭐하는 용도인지 모르는 경우도 자주 봤습니다. ebuild 자체의 진입장벽은 낮지만 "이것이 왜 아름다운지" 에 대한 이해에 걸리는 진입장벽은 높은편에 속합니다. 대신에 알고나면 아는 만큼 "아름답게" 구성할 수 있다는 양날의 칼같은 성격을 지니지만요.

CFLAGS의 적용으로 볼 수 있는 장점을 미친듯이 강조하는 행위는 컴파일러 myth의 연장선으로 꼽습니다. 마이크로벤치로는 차이가 나지만 (느낌탓(:p)을 제외한) 실 체감에서 _들인만큼의 공_을 뽑기 힘들다는 사실을 알아야 합니다. CPU가 쿼드건 싱글이건 클럭이 높건 낮건 상관없이 적용됩니다. 차라리 잘못된 커널 설정으로 제너릭하게 설정된 커널보다 낮은 퍼포먼스를 보여주는 경우를 피할려고 노력하는게 더 나을지도 모른다는 거죠.

제가 보는 젠투의 장점은...

먼저, 시스템 전체적으로 사용하는 빌드 환경을 조작하는데 있어 유연성을 가지는 것에서 장점을 꼽습니다. gcc 3.3.x 와 gcc 4.x를 필요할 때마다 _기본적으로 제공하는 한번의 명령_으로 system-wide 에 적용시켜주는 배포판은 흔하지 않습니다. *-config 시리즈의 툴 사용용도를 아신다면 다른 환경역시 손쉽게 조작할 수 있지요. 뭐, 예전에 일하던 회사에서 *-config 에도 불구하고 (자신의 기준에서) java개발 환경을 구성할때는 악몽이다.. 라고 종종 말 하시던 분도 계셨었으니, 모든 분들께 만능은 되지 못하겠지만요.

두번째는 젠투 사용자분들이 흔히 쓰는 "새끼친다"라는 표현이 주는 장점이죠. 이건 지리즈님께서 언급을 하셨었으니 넘어갑니다.

세번째는 ... 뭐 이건 Arch Linux 같은 경우에도 해당하지만, 패키지 설치할 때 -dev로 나뉘지 않고, 문서 역시 doc USE flag만 주면 선택적으로 한번에 설치할 수 있고, 또 하나의 패키지 명으로 관리할 수 있다는걸 꼽겠습니다.

뭐 더 끄집어낼 수도 있겠지만 제가 글실력이 없는 관계로, 위에서 언급한 것들도 조금 억지스러운 면이 보이는 것 같아서 여기서 끝낼렵니다.

배포판은 개인적인 선택에 따른 호불호의 관점이 많이 작용하기 때문에 뭐가 좋고 뭐가 나쁘다는 이야기는 무의미합니다. 어떤 배포판이든지 자신이 가장 잘 아는 배포판이 가장 아름다운 배포판인거죠 :)
------
http://lunapapa.egloos.com , me2day : lunapapa , IRC: LunA_J`etch@#gnome

지리즈의 이미지

주의 사항을 블로그 본문에 언급할 필요가 있겠습니다.

Gentoo 유저로서 USE Flag의 정확한 의미를 알기 어렵다는 것과
이것들의 사용에 대한 선험자의 조언을 접하기가 어렵다는 것이 가장 큰 어려움이었습니다.

There is no spoon. Neo from the Matrix 1999.

There is no spoon. Neo from the Matrix 1999.

dalgarak의 이미지

사실 USE flag에 대해 잘 알지 못하는 경우에도, 프로파일(make.profile)의 연결만 자신이 원하는 목적에 맞게만 해줘도 system-wide에 적용되는 USE flag를 "기본은 될 정도"로 구성할 수 있습니다.

가장 보편적으로 많이 사용하는 x86을 예로, 초심자가 데스크탑의 용도로 구성한다고 가정해봅니다.

/usr/portage/profiles/default-linux/x86/2006.1/desktop 내의 make.default 입니다. 물론 parent인 2006.1 디렉토리의 make.defaults는 당연히 베이스로 깔고 들어가겠지요.

(화면을 넘어가서 약간의 줄넘김 조작을 했습니다)

STAGE1_USE="nptl nptlonly unicode"
 
USE="alsa arts cairo cdr dbus dvd dvdr eds emboss encode esd fam firefox gif \
gnome gpm gstreamer gtk hal jpeg kde ldap mad mikmod mp3 mpeg ogg opengl oss png \
qt3 qt4 quicktime sdl spell truetype vorbis win32codecs unicode X xml xv"

어떻게 생각되십니까? 기본적으로 emerge world를 땡겨주고, emerge gnome 또는 emerge kde를 했을 때 최소한 audacious / mplayer / 그 밖의 gstreamer 기반의 미디어플레이어를 사용했을 때 코덱에 대해서 고민할 필요가 없는 구성이 갖추어집니다. 또한 gnome을 설치했을 때 gnome-panel, gnome-applet 등과 evolution data server의 연동 역시 기본적으로 됩니다. (eds USE flag가 포함되어있습니다.)

잘못된 경우를 예로 들어볼까요? 극단적인 경우이긴 하지만, 2006.1 x86 stage3에서 한 때 기본으로 되어있던 default-linux/no-nptl 같은걸 사용하면, 문제는 심각해질 수 있음을 알 수 있습니다:

unicode를 지정안한 상태에서 여느 매뉴얼에서 권장할 만한 ko_KR.UTF-8을 시스템 로케일로 잡아놓은 후에 "어떤프로그램 --help"를 하니 메시지가 xterm 에서 깨져보여요.. 이런 케이스를 예로 들을 수 있습니다. (설치/활용 질답란에서 찾을 수 있습니다)

덧: 말하고자 하는 바는, 많은 gentoo 설치 관련 문서들이 make.default 의 중요성을 생각보다 크게 인식하지 않다고 하는겁니다. 초심자들이 가장 먼저 접하는 문서들임에도 불구하구요 :(
------
http://lunapapa.egloos.com , me2day : lunapapa , IRC: LunA_J`etch@#gnome

skyoon의 이미지

무작정 젠투를 설치했던 제 모습을 뒤돌아보는 계기가 되었습니다.

처음 컴파일 최적화를 중요포인트로 생각했지만...

글을 읽고나니 젠투라는 배포본의 특성을 잘 몰랐던거 같네요.

좋은 글 감사합니다.

kaos009의 이미지

젠투 유저로서 생각할것이 많게 하는 글이군요

요즘은 usr.gentoo.or.kr 에도 사용자가 줄은 것 같아 많이 안타깝습니다.

대학생때만 해도 꽤 활발했던거 같은데..
----------------------------------------------------------
변화를 추구하며....

변화를 추구하며....

까나리의 이미지

데비안이나 우분투와는 뭔가 다른게, 게을러지지 못한다는 장점(?)이 있습니다. Gentoo 는 변화에 민감해야합니다. 설정파일들이 어디로 숨어버리는지, 관심을 두지 않으면 바뀌어져 있습니다.위에서 언급한것처럼, 퍼포먼스의 차이 때문에 Gentoo 를 쓴다고 생각하지 않습니다. 사용하고 싶은 옵션을 지원하주지 않을때 원하는대로 사용할 수 있고 portage 시스템의 강력함을 맛본 사람이라면 쉽게 떠나질 못하죠. Gentoo 를 사용안하고 CentOS/Ubuntu 로 전향한지 1년정도 되었는데 LiveCD 는 나올때마다 받아둡니다. 그나저나 2007.0 은 언제 나오나요?

http://kkanari.egloos.com/

dalgarak의 이미지

모를일이지요 (....) 3월이 계획이었는데 아직까지 나오질 않았으니깐요.
벅질라 보면 라이브CD관련해서 pre-release 판의 버그도 올라와 있고.. 진행중이긴 한듯 합니다.

상관이 없는게, 우분투 CD나 FC 1번장이나 뭐 대강 구해서 부팅만 하면 그 다음부터야 별 상관이 없는것도 이이유이긴 하지만요 :크크:

sabayon이나 vlos 같은 gentoo 기반의 바이너리 배포판이 그 간격을 메워주고 있기도 한듯 합니다.
------
http://lunapapa.egloos.com , me2day : lunapapa , IRC: LunA_J`etch@#gnome

ganadist의 이미지

며칠전에 profile디렉토리에서는 dev 딱지가 떼였던걸로 알고있습니다만;;

----
데스크탑 프로그래머를 꿈꾸는 임베디드 삽질러

highwind의 이미지

젠투쓴지 벌써 4년이 넘어가는거 같은데요. 쓰는이유는 단 하나... portage가 좋아서입니다.
속도 빠른것 모르겠고 그냥 USE랑 emerge하는게 잼있어서... ^^;;

=====================================
http://www.timothylive.net

=====================================
http://timothylive.net

falaris의 이미지

아 저는 작년에 10개월 동안 업데이트 안했다가 한번 업데이트
하려다 피 보고 ㅠ.ㅠ

......
아저씨가 되가는 느낌이다. 싫다...
절대 아저씨는 아닙니다( 꺽였을 뿐이에요 ㅠ.ㅠ )

wpcasper의 이미지

안녕리눅스 만세!!

글 잘 읽었습니다. 저같은 사람은 젠투를 쓰면 안될것 같습니다. 아흑..
귀차니스트라면 안녕리눅스로.. 김정균님 만쉐!!

"운영자가 어설프다면" 젠투가 서버로 부적절하다는 말씀은 충격이네요.
좋은 말씀 감사드립니다.

bus710의 이미지

주변의 도움으로 젠투를 잘 쓰고 있는 관계로 쉽게 벗어날 수가 없습니다^^

'처음에는 원하는 것만 깔린다'는 것 때문에 쓰기 시작 했는데 아직 초급 유저인 관계로 지리즈님께서 쓰신 글은 좀 더 조용한 곳에서 천천히 읽어봐야 겠습니다...

포팅을 위해서라면 젠투가 괜찮지 않나... 하는 생각이 드는데요.
특별히 다른 곳에서 소스를 구할 필요 없이 메인과 타겟 간에 소스를 공유하기 편할 같습니다.

akudoku.net

life is only one time

jachin의 이미지

젠투의 빌드시간을 생각해보면 결코 좋은 배포판이라는 생각이 들지는 않겠습니다만,

젠투만큼 새로운 '실험'을 가능하게 하는 배포판은 없다고 생각합니다.

이미 젠투를 활용한 많은 프로젝트 문서가 공개되어 있고,

그 프로젝트를 통해 아무리 어려운 과정이라도 문서를 읽고 쉽게 접근할 수 있다는 점이

젠투 리눅스의 최대 장점이라 생각합니다.

따라서 전 초보자들 분들에게 적극 권장하고 싶습니다.

물론 최신의 PC 사양을 갖으신 분들일 수록 이러한 장점은 극대화되죠...
====
( - -)a 이제는 학생으로 가장한 백수가 아닌 진짜 백수가 되어야겠다.

ydhoney의 이미지

뭐 저 위쪽 정균옹께서 할 말씀은 다 하신듯 싶으니 패스하고..

일단 서버라는 측면에서 생각할때 RHEL등을 가장 최우선적으로 고려할 수 밖에 없는 이유는 "성능" 이라던지 "보안" 이라던지 하는것이 아니라. 최대한 시중에서 판매되고 있는 어플리케이션과 하드웨어들에 대한 "범용성" 을 중심에 두고 생각해야 하기 때문입니다.

잘 기억은 나지 않습니다만, 일전에 김정균님의 안녕리눅스가 언급되었던 쓰레드였던걸로 기억을 하는데, 당시 제가 안녕리눅스에 대해서 이야기하면서 "개인이 만드는 배포판에는 한계가 있다" 라는 뉘앙스로 안녕리눅스를 폄하하였던 적이 있었을겁니다.

이조차도 결국 핵심은 무슨 성능이 어떻고 의 이슈라거나 하는것이 아니라 일단 범용성이 문제가 되기 때문입니다. 안녕리눅스를 최근에 발표되고 있는 우드크레스트 기반의 서버들이라거나, 썬에서 나오는 x86_64 기반의 서버들에 포팅하려면..아 물론 할 수는 있을겁니다. 드라이버도 제공되겠다 못할 것은 없겠지요. 대신 무진장 삽질을 해야하지요.

Linux SE로써 가장 우선순위에 두어야 할 것은, 일단 별다른 조치없이 OS가 설치가 가능한가 라는 문제를 접하게 됩니다. 일반적으로 단일사이트를 운영하는 분들이야 자기네 사이트에 있는 하드웨어 하나만 일단 어떻게든 설치가 완료되면, 그걸 가지고 dd copy를 해버리던 뭘 하던간에 한 번의 설치 이후에는 별다른 이슈가 없이 운영하시고, 하드웨어에 문제 생기면 하드웨어 부품 교체나 하면서 편리하게 보내실수도 있을겁니다. 하지만 그런 경우가 아니라면? 저같은 경우는 분명 레드햇 기술지원을 하는 엔지니어이고, 업무를 하면서 상당히 다양한 하드웨어와 어플리케이션을 접하게 됩니다. 일반적인 SE들이 특정 사이트에서 평생 SE를 하면서 접하는 정도의 주요 설치건 및 기술적 이슈에 부딪히는 정도를 한두달 사이에 모두 부딪히는 정도랄까요? 그렇다보니 일단 단순 서버 하드웨어건, 서버에 추가되는 주요 인터페이스 카드들, 하다못해 Infiniband 등의 10Gbps Based 장치들이나 기타 스토리지나 테잎장치 등등..만지는 장비들도 한두가지가 아니고 단순한 구성도 아니지요. 하드웨어 Certification에 맞춰서 셋팅준비를 하고 가면 어플리케이션 Certi가 되지 않아 이를 조정하는데 몇시간이고 시간을 소모하기도 합니다.

과연 이런 구조에서 Gentoo를 손쉽게 추천할 수 있을까요? 적어도 제 대답은 No입니다. 추천이 문제가 아니라 일단 사용이 불가능하다고 보시면 됩니다.
 
====================여기부터 식인어흥====================
어흥 몰라 어흥? 호랑이 어흥!! 떡 하나 주면 어흥!! 떡 두개 주면 어흥어흥!!

송효진의 이미지

상황이 배포판을 결정하네요.

후임에게 젠투를 가르쳐줄지 RHEL 로 갈아탈지 고민해 보고도 싶고,

고가장비 설정을 젠투로 해 내는 경험도 해 보고 싶습니다.
그냥 lspci 해서 이름 맞춰 커널 옵션 주면 끝나는 것들밖에 못만져봤습니다.

emerge money
http://wiki.kldp.org/wiki.php/GentooInstallSimple - 명령어도 몇개 안되요~

지리즈의 이미지

납품하는 입장(S.E)과
시스템을 구축하고 장기적인 유지보수를 고려하는 입장(S.I)은 차이가 있다고 보입니다.
초반의 삽질에 대한 댓가와 장기적 운영에 대한 이득을 저울질 했을 때 차이라 할까요?
또한 OS가 안정적으로 런칭이 되느냐와 OS위에서 돌아가는 어플리케이션의 안정성과 효율 및 유지보수를
고려하느냐도 차이도 있을 것입니다.

한두대 납품하거나 혹은 아주 보편적인 용도로 서버가 운영된다면 RHEL계열을 선택할 겁니다.

저보고 클러스터를 구축하라고 하거나,
혹은 웹하드의 파일서버 용도, 혹은 미들웨어 등을 구축하라고 한다면,
Gentoo를 선택하겠습니다.
또한 운영하는 장비댓수가 많아지면 많아질 수록 Gentoo가 더 낫다는 생각도 해봅니다.

Gentoo는 범용성은 떨어지지만, 확실히 특화된 시스템에 더 효율적인 면이 있습니다.

There is no spoon. Neo from the Matrix 1999.

There is no spoon. Neo from the Matrix 1999.

김정균의 이미지

제가 원래 하고 싶었던 말은.. 일반화를 하지 말자는 의미였습니다. "Gentoo 가 더 낫다" 에 "나에게는" 이라는 것이 붙어 주는 것이 어떨까 하는 겁니다. :-)

대부분의 사람들에게는 아무리 좋은 시스템을 가져다 주어도, 익숙한 것이 가장 낫은 법이거든요 ^^;

Zentoo 로 많은 시스템을 관리하는 방법에 대한 글 같은 것이 공유가 되어 있다면, 님의 의견에 동조를 하는 사람이 더 많아질 테고, 그렇다면 Zentoo 가 주류가 되어 ydhoney 님이 말하는 범용성 같은 것도 해결이 될 수 있다고 봅니다.

그리고, 한가지.. S.E 가 OS 만 관리한다면 좋겠지만, 저 같은 경우에는 OS 관리는 맡은 일의 1/100 정도 밖에 되지를 않습니다. 그렇기 때문에 절대 커널 컴파일 같은 것은 하지 않습니다. 커널의 TCP TIMEWAIT 값을 30초에서 3초로 줄이면 서버를 1/10 으로 줄일 수 있지만.. 이 일 보다 다른일이 더 많거든요 ^^; 무슨 의미인지 아시라 믿습니다. 야동꿀벌님이 말씀하신 그냥 배포본에서 기본으로 지원! 이 아주 중요하다는 의미입니다. 장비 선택시에도, addon driver 가 필요한 장비는 선택 대상에서도 제외가 됩니다. :-) 몇백대 설치해야 하는데 서버마다 addon 처리하기도 귀찮고, PXE 설정 하는 것도 귀찮고.. 그냥 되어 있는데서 되어야 다른 업무에 지장이 없습니다. :-)

어쨌든 원글의 의도는 상당히 공감이 갑니다. 제가 하고 싶었던 말들이었거든요. 추구하는 방향은 다르지만, 나름대로 이런 부분에 관심을 가지면서 정리를 하시는 분들이 하나씩 생긴다는 것은 아주 좋은 방향이라고 생각됩니다.

onion의 이미지

흑... zentoo가 아니라 gentoo에요...T.T

-----새벽녘의 흡혈양파-----

-----새벽녘의 흡혈양파-----

지리즈의 이미지

부족한 글에 대한 답글 감사드립니다.

There is no spoon. Neo from the Matrix 1999.

There is no spoon. Neo from the Matrix 1999.

onion의 이미지

제목은 좀 거시기합니다만.....
요즘 실전에서(?) linux가 가지는 되도 않는 한계를 주절거려보고자 끄적이기 시작합니다.

redhat 9.0과 fedora core 6의 APM 사용에 있어 차이점은?
.......못쓰겠답니다... 최신하드웨어에 레댓 9.0 깔아달랍니다..
깔리지도 않는데... 개인적으로는 꽤나 화가 납니다..
젠투는 이런건 없어요..... 언제나 그나물에 그밥...
젠투 install guide....1.2 이후로 부분부분외에는 찾아본 기억이 없는거같습니다.
....
그래요.. 맞습니다.. 사실 다른 배포판은 install guide 볼 필요도 없습니다...T.T

그리고 아무래도.. 최적화라기보다는.. 맞춤이라는데 의미가 더 큰거같습니다...
최적화도 사실 좋지만..(씨이익)
원하는대로 안되는거 없이 다 되게 해주는게 꽤나 맘에 든다고나할까요...
이런 목적에서 CFLAGS와 USE는 저에게는 가뭄의 단비같은 존재입니다.

빌드의 압박은... distcc로 풀고있습니다...
distcc...참 좋아요....물론 주변에 젠투를 쓰는 사람.. 또는 컴파일러 버전이
같은사람이 나보다 좋은 cpu를 쓸때에 한해서 좋습니다..(먼산)

...인정하기는 싫지만 중급자 이상을 위한 시스템은 맞습니다..
다른건 다 넘어가면서.. 왜 다들 파티션에서 헤메는지...
제가 이상하게 가르치는걸까요......
요즘은 포기하고 CentOS 또는 우분투를 권하고 있습니다..-.-;

얼리어댑터를 위한건 아닌거같습니다...
젠투.. 아직 gnome 2.18 정식릴이 안됐습니다...(뭔가 맺혔다...)
잠시나마.. 우분투가 부러웠던 순간이었습니다...
(별외로.... 패키지중 마이너한건 의외로 버전 낮습니다.. 뭐 이빌드 만들어쓰면 그만이지만...
vi도 못하는 사람이 할 수 있을만한건 아니지요..-.-)
.....그래요.. 강제로 손컴파일해서 2.18 올렸습니다..(울먹)
......사실.. udev관련.. utopia계열이 꼬이면 피를 보기도 합니다..-.-;
더군다나 이번에 날로먹는 부품이 있어 결행하였던
부품업글후.. 폐해가 큽니다.. amd에서 intel로 왔거든요..(침울)

솔직히 안정성은 RHEL에 한표.... 생각없이 쓰기에는 최강..
업데이트가 늦어야 하는 이유... 지금은 알것도 같습니다..-.-;

많은 장점에도 불구하고 장점을 뛰어넘는 몇가지 큰 접근장벽때문에
젠투를 권하기는 쉽지 않습니다.
여기에는 꽤나 오래전에 linux를 접할때의 열정이 지금은 남아있지않아서
다른이에게 무언가를 권하면 그에 따르는 책임을 져야하는걸
더이상 귀찮아 하게된 제 자신에게도 원인은 있는거같습니다.

하지만 그럼에도 불구하고 저한테 젠투는 아직 가장 좋은 환경이며
아마도 다른것으로 옮기기는....
쉽지 않을거라 생각합니다.

그리고 제가 관리하는 서버는 젠투도 좋습니다...
glibc컴파일하는데 12분...(아하하하하)
SAS.....gentoo를 위해서 나온 device가 아닌가..하는 착각이 들게 해주더라구요...T.T

-----새벽녘의 흡혈양파-----

-----새벽녘의 흡혈양파-----

지리즈의 이미지

오라클 8i 때문에,
7.3으로 납품해야 하는 경우도 있습니다. ㅠ.ㅠ.

아 그 때 삽질하지 말고 Gentoo로 갈껄...

There is no spoon. Neo from the Matrix 1999.

There is no spoon. Neo from the Matrix 1999.

frenzy의 이미지

한때는 레드햇7.2 를 가지고 적절한 기능(xfs, apt, 커널변경등...)을 추가하고
필요없는 기능들은 뺀 서버에 적합한 리눅스를 만들어서 사용했었습니다.
(김정균님의 안녕리눅스와는 비교할 수 없을 만큼 단순했었습니다...)
혼자서 6개월을 운영하기 힘들더군요. 회사원의 한계인가요?

이제는 서버가 수백대 규모가 아니라서,어떠한 경우라도 서버의 컴파일을 자제합니다.
(클러스터나 특별한 시스템 구축시에는 컴파일 - 커널, 서버데몬 - 을 합니다. 성능이 아니라 일관성때문에... ^^;;)
이런이유로 리눅스는 레드햇(centos)이나 데비안이외에는 눈도 돌릴 수가 없습니다.

결국 다른 서버관리자분들도 마찬가지겠지만, 서버관리, 프로그램작성, 네트웤관리, 기술상담 그외에
어느회사에나 있는 다양한 일들... 시간을 갖기위해서는 어쩔 수 없는 선택입니다.

(현업에서 종사하는 사람의 푸념입니다...)

+
++++++++++++++++++++++++++++++++++++++++++++++
혼자놀기의 도사가 되리라... http://geeklife.co.kr

.
++++++++++++++++++++++++++++++++++++++++++++++
혼자놀기의 도사가 되리라... http://geeklife.co.kr

codebank의 이미지

좋은글 잘 읽었습니다.
제가 머리가 나빠서 답글들 보면서 원글의 글이 어떤 글이였는지는 잊어버렸습니다. -.-;

하지만 제가 Gentoo를 선택했던 이유를 가만히 생각해보니 김정균님의 말씀처럼
패키지 관리툴때문이었더군요.
제가 Redhat을 사용하다가 Gentoo가 나오자 긴 컴파일 시간에도 불구하고 Gentoo를 고집했던
이유가 패키지 관리때문이었죠.
Debian계열은 그냥 안써지게 되었고요.
그래도 Linux를 접하겠다는 사람들에게는 Redhat계열 > Debian계열 > Gentoo 순으로 권합니다.
사실 어떻게 하라고 설명하기가 귀찮아서... :-)

어쨌든 저는 다른 이유는 둘째치고 패키지 관리툴 때문에 Gentoo를 선택한 것 같습니다.
------------------------------
좋은 하루 되세요.

------------------------------
좋은 하루 되세요.

nahs777의 이미지

서버의 측면에서는 솔직히 전 잘 모르는 일이라. 넘기고..

사실 저도 젠투를 잠시 써본적이 있는데, 다른건 다 놔누더라도, 이건 운영체제를 '사용' 하는건지 아니면 운영체제를 '만드' 는 건지 구분이 안될정도의 업그레이드 압박이 계속되더군요.. 켜서 하는일의 80%가 빌드.. 최적화... 어느순간 질려버려서 더 이상 못쓰게 되더군요...

모두 RHEL 이 서버용으로 좋다고 말씀하시는것은, 하드웨어 지원, 그리고 문서화의 영향이 크다고 생각됩니다. RHEL은 서버군에 대한 문서가 정말 다양하더군요. 그런점에서 멋진 운영체제라고 생각합니다. 그러나 뭔가 약간 아쉬운점은, 리눅스 배포판의 핵심이라고 볼수 있는 패키지 관리가. 사실 불편합니다. 뭐 dpkg + apt 나 rpm + yum 이나 장단점은 있겠지만, 사실 전자가 좀 편리한 맛은 있죠. 사실 저뿐만 아니라 많은분들이 rpm 불편하다고 느끼실만한데, RHEL 쪽에서 좀 개선하려고 하지않는게 이상합니다..(fedora 다음배포판인가에서 개선책이 나온다고는 알고 있습니다.)

전 서버를 운영할일은 없어서, 그냥 ubuntu 씁니다.. 저한테는 그냥 잘 맞더군요..

김정균의 이미지

사실 저뿐만 아니라 많은분들이 rpm 불편하다고 느끼실만한데, RHEL 쪽에서 좀 개선하려고 하지않는게 이상합니다.

할 이유가 없기 때문입니다. rpm 은 package manager 가 아닙니다. Redhat 에는 up2date 라는 훌륭한 package system 이 있거든요. 다만.. 서비스 fee 를 낸 사람들만 사용을 할 수 있죠. 그리고 yum 도 쓸만하고요. apt-get 도 쓸만합니다. 굳이 새로 나와야 할 이유가 없겠죠.

제가 안녕 리눅스의 Packages System (pkgadm) 을 만들때, yum 이 떠오르던 시기였는데, yum 이 떠 있었다면.. pkgadm 을 만들지도 않았을 겁니다. :-)

rpm 은 불편할 것이 없습니다. 다만 rpm 을 관리해 주는 manager 들이 예전에는 없었을 뿐이죠. (예전에도 up2date 는 있었습니다만.. (공개로) 사용하시는 분들이 거의 없었죠..

alwaysrainy의 이미지

웬간해서는 배포판을 갈아타지 않는 스탈이라서 ㅡ.ㅡ;;
무자게 게으른가 봅니다. gentoo, debian 서버 각각 한대씩을
운영했었는데, 그냥 그런가 보다 하구 썼습니다.
아직도 초보라서 윗분들의 전문적인 이야기는 솔직히 크게 와닿지는 않구요.. ^^;
emerge.. aptitude.. 그런데 개인적으로 dpkg 패키지 관리 방식이 좀
더 편하지 않나 싶습니다. 체감해보면 성능의 차이도 매우
미미한 것 같고.. 패키지 업데이트도 더 빠른 것 같고..

개인적으로는 debian 계열을 사용하면서 가끔 ~ 소스 컴파일 설치가
익숙합니다. 간혹 바이너리 설치는 불필요한 기능들이 너무 많이 포함되서
찜찜하더라구요.

그리고 Embedded System에 Gentoo 포팅 관련 프로젝트가 진행중인가요?
LFS 방식이나 QPlus 보다는 훨씬 매력적일 것 같은데.. 구글링 좀 해봐야겠습니다 ~ ^^+

---------------------------------------
세계는 넓고, 할일은 많다.

---------------------------------------
세계는 넓고, 할일은 많다.

onion의 이미지

zaurus용 gentoo :: 망했....
ps2용 gentoo :: 망했....
xbox용 gentoo :: ...pc랑 대체 뭔차이가..-.-;

사실 gentoo가 들어간다면...
nfs를 통한 compile temp와
cross compile distcc정도를 구비해놓으면
나름 쌈박한놈이 아닐까 싶습니다..
임베디드 시스템 자체적인 컴파일은 압박이 너무 심해요...T.T

-----새벽녘의 흡혈양파-----

-----새벽녘의 흡혈양파-----

falaris의 이미지

글 잘 읽었습니다.......
아저씨가 되가는 느낌이다. 싫다...
절대 아저씨는 아닙니다( 꺽였을 뿐이에요 ㅠ.ㅠ )

nathaniel7687의 이미지

6년전 글인데도 보면서 얻어가는 지식이 많네요 감사합니다! :)

댓글 달기

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

BBCode

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param>
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

Textile

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • You can use Textile markup to format text.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Markdown

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Plain text

  • HTML 태그를 사용할 수 없습니다.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 줄과 단락은 자동으로 분리됩니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.