소스 컴파일과 바이너리 설치 중 어느 방법을 더 선호하십니까?

사용 목적에 따라서 조금은 달라지지 않을까요?
조금이라도 포퍼먼스를 생각한다면 컴파일이 분명히 좋은건 알고 있을것 입니다.
자신의 머신에 최적화를 하니꺼니까요..
요즘 하드웨어 스펙자체가 워낙에 좋다 보니까 바이러리 설치를 해도 별 문제가 없는거 같습니다.
그런데, 만약에 서버의 행동을 해야 한다면, 조금이라도 포퍼먼스를 생각해야 한다면, 한명의 접속자라도 더 늘려야 하는 경우가 발생한다면...

제 생각으로는 상황에 따라서 틀린것 같습니다.

한두대도 아니고 수십대나 되는 실무 환경에서
단지 사용(운영)을 위한 설치를 할때 컴파일은 정말 비생산적인 일이라고 생각합니다.

그 이유로 인하여 퍼포먼스에 문제가 있다면 하드웨어를 업그레이드 하는것이
장기적으로 회사에 더욱 이익이었습니다.

그리고 컴파일이 더욱 퍼포먼스가 안나오는 경우도 있더군요.
대표적으로 Mysql... 제 아무리 컴파일 옵션 설정해서
이것저것 해봐도 mysql.com 에서 배포하는 바이너리보다는
확실히 성능이 떨어지더군요.

컴파일 설치는 설치할 때도 문제지만 유지보수까지 생각하면 끔찍합니다.
개인적인 용도라면 몰라도 실무에서 쓰기는 불가능할 듯.

그냥 소스를 직접 가져다가 스크래칭으로 빌드하고 설치하는 건 선호하지 않습니다만..

젠투같은 식으로... 이 소스를 빌드해서 어디에 설치했는지... 또 어떤 버젼을 설치했는지 등의 정보가 남아있는 경우는 좋습니다 :) 업데이트된 버젼이 있는지의 체크도 아주 간단하고... 또 필요가 없어져서 제거를 하려는 경우에도 깨끗이 제거가 가능하니까요...

소스를 가져다가 여기 저기 빌드해놓으면... 다른 사람이 구축해놓은 곳을 넘겨받은 경우 실행 파일/설정 파일들 찾는거부터 짜증이 밀려오더군요 -_-;;

레댓이라면 rpm -ql apache | grep conf / 젠투라면 epm -ql apache | grep conf 로 찾으면 될 걸.. 어렵게 돌아가는 느낌이었습니다 -_-;;

하드웨어 환경이 대부분 통일되어있는 현 상황에서... 자신의 머신에서 돌리는 컴파일이 실제로 성능 향상을 가져오는지 궁금합니다.

젠투가 빠르고 가볍게 느껴지는 것은 컴파일 설치 때문이 아니라 설치 시간이 지독하게 오래 걸리기 때문에 쓸데없는 것을 안까는 습관이 생겨서 그런 것이라고 개인적으로 생각하고 있습니다.

웹이나 파일서버, 혹은 데스크탑 환경에서 직접 컴파일하여 최적화한 시스템이 어느 정도의 마진을 끌어낼 수 있는지 조사된 자료를 아시는 분이 있다면 링크 하나 부탁드리겠습니다. :oops:

다르게 생각하면 컴파일 속도가 예전보다 빨라졌기 때문에 소스 컴파일도 할만하다라고 생각할 수 있지 않을까요? 8)
사실 gentoo에서 몇몇 package를 제외하고는 크게 불편함을 느낄정도는 아닌데요.

저도 젠투를 쓰는데 소스 컴파일 하는것이 예전 빨간모자 쓸때보다

하드 용량을 적게 잡아먹더군요. 그리고 쓸때없는 데몬들을 설치안하고 또 /etc 밑이 깔끔해 져서 소스 컴파일을 선호하는것 같습니다.

소스 컴파일 그게 뭐죠?
제가 나름대로 검색을 해 본 결과에 따르면, 긁적 긁적, 무슨 양념인것 같은데.
알려주세요. :)
-마이크로소프트 윈도우 사용자로 부터-

같은 CPU, 같은 아키텍쳐를 갖는 컴퓨터끼리라면 소스컴파일 한 결과값을 공유해도 될 것 같습니다. 물론 지금의 젠투 배포판도 같은 형태이긴 하지만, 조금은 일반적인 CPU 분류에 따라 패키지 관리를 하고 있으니까요,

같은 계열의 CPU, 메인보드 칩셋을 사용하는 사람들끼리 모여서 중앙 컴파일을 맡을 사람, 버전 관리 할 사람, 패키징 할 사람이 같이 몇 시간 작업하면서 업그레이드를 해가는 것이 좋지 않을까 생각합니다.

한 국가 안에 아무리 적어도 같은 계열 CPU, 같은 메인보드 칩셋을 쓰는 사람이 10명 정도는 되지 않겠습니까?

온라인 포럼도 갖고 패키징도 서로 잘 관리하면 높은 효율로 높은 성능을 볼 수 있으니 좋을것 같습니다.

저는 젠투를 사용합니다.
저도 요즘같은 고사양에서 소스와 바이너리의 실행속도차이가 거의 나지
않는다는것을 인정합니다.
amd64를 사용중인데 수세나 젠투나 뭐 별로 못느끼겠더군요
물론 수세가 약간 느린.. 이건 튜닝의 문제겠지요
그러나 소스컴파일방식을 선호하는것은 실험적인 패키지버전을
사용할수 있다는겁니다. 다른 바이너리 배포판보다 소스컴파일 기반
배포판이 업데이트가 빠른게 사실이니까요.. 그냥 남들보다 미리 써본다
는거 그 맛에 씁니다. 바이너리배포판에선 보통은 안정패키지를 고수하니
까요 물론 서버나 중요한 시스템이 아니라 개인컴퓨터에서지요.
뭐 사람마다 취향이 다르니 서로 인정해야겠지요~!!

비공식 패치 부분은 정말 그런 것 같습니다. 페도라같은 경우는 소스 RPM을 받아서 스펙 파일을 수정해야 하는데, 쉽지 않습니다.

데비안의 경우 소스패키지가 있고요.
옵션주어 빌드하고 바이너리 패키지로 만들수 있는것으로
알고 있습니다.

'바이너리 설치가 좋다!!'

라고 생각하던 차인데 글들을 읽다보니 젠투의 패키지 관리가 너무 끌리는군요...

저는 바이너리냐 컴파일이냐 보다는 패키징이냐 아니냐에 관심이 더 많아서...

그래도 개인적으로 바이너리에 한표입니다.

컴파일은 이리저리 해줘야되는게 귀찮아서..

항상 느끼는 거지만 젠투에서 그놈을 컴파일해서 사용할때와 데비안에서 그놈을 바이너리 설치할때 도대체 둘의 차이가 뭔지 알수가 없습니다.
커널의 경우에도 커스터마이징 후 컴파일 한 것과 데비안에서 패키지로 지원해주는 바이너리 커널이랑 속도차이가 나는지도 모르겠습니다.

서버의 경우에도 컴파일 한 것과 바이너리로 해놓은 것들 중 어느 것이 더 빠르고 많은 수의 사용자를 있는지도 별 차이가 안나는 것 같습니다. 고로, 서버든 일반 데스크탑용이든, 엄청난 시간을 투자해야하는 컴파일 설치보다는 바이너리 설치쪽이 훨씬더 생산적이고 효율적이라고 생각합니다.

젠투의 존재로 인해
고사양 하드웨어 '서버' 에서 바이너리 vs 소스컴파일 의 논쟁은

젠투 의 승리 입니다. :twisted:

사용자가 내리는 설치 명령은 바이너리 설치와 별 다르지 않습니다.
위에 예로 설명해주신 분은 unpack compile merge 로 설명해 주셨는데,
그냥 ebuild 파일 내에 epatch 패치파일 한줄 적어주고,
emerge 패키지 하면 그냥 됩니다.

젠투 시스템의 /etc 를 둘러보세요.

패키지의 설정들이 참 보기 좋게 되어 있어서
처음 설치해 본것도 웬만한것은 손쉽게 설정할 수 있었습니다.

아파치 모듈용과 쉘용 바이너리의 php.ini 파일 경로가 다릅니다.

아파치는 각 모듈별 설정이 modules.d 에 70_mod_php5.conf 와 같이 따로 들어있고,
conf.d/apache2 파일에 -D PHP5 옵션으로 로딩하도록 되어 있습니다.
보기도 쉽고 넣고 빼기도 쉽죠.

특히 qmail 설정의 tcp.smtp 파일의 경우

cd /etc/tcprules.d
make *.cdb

http://www.gentoo.org/doc/en/qmail-howto.xml

젠투 qmail 설치문서 입니다.
정말로 이게 끝입니다. 8)

젠투가 이겼다니까요. :D

글쎄요. 제 실력부족탓이 컸겠지만 바이너리 설치에서 의존성 문제를 해결하는 것이 그리 쉽지는 않았습니다.
a를 깔려다가 b가 필요하다고 해서 b를 깔았는데 엉뚱하게 c가 동작안하게 되었다던지 등등.
상황에 따라 틀린 문제이긴 하겠지만요.

yum 이란걸 씁니다. 찾을때는 yum list | grep gcc 이런식이고.. 만약

gcc.i386 base

라고 결과가 나오면 yum install gcc.i386 과 같이 하면 됩니다.
커널도 yum 으로 업그레이드가 되죠.. 그놈에 들어가서는 빨간 느낌표가 빤짝이고 있으면 더블클릭하고 next 몇번 누르면 최근 업그레이드된 패키지도 다 받아서 설치해주고요.. 정말 리눅스 편해졌습니다..

보통 바이너리 배포판에, 필요한 프로그램들을 하나하나 소스를 가져다 설치하고 있는데요... =.= 왠지 어중간 하네요.

아무튼 둘중 하나만 선택하라고 물으신다면, 소스쪽을 선택하겠습니다.

좀 느리게 설치되긴 하지만, 뭔가 재밌는걸 해볼수 있는 여지가 있기 때문입니다. 어떤 프로그램은 소스의 아주 일부분만 고쳐도 한글로 잘 되기도 하고, 또 최적화(-O)도 해볼 수 있고, 소스 들여다보면서 뭐하는건지 설치전에 구경도 할 수 있고요. 또 소스를 직접 컴파일해보지 않았다면, 모질라의 컴파일이 두시간이 걸리고, 엑스와 그놈 또는 KDE환경을 컴파일하는데 한나절이 넘게 걸린다는 것도 몰랐겠죠.

젠투는 최적화가 아니라 유연함이라는데 동조합니다.

대개 영상물을 DVD 로 보게 되면 '화질향상' 쪽에 신경을 쓰는데, 막상 DVD 입문하면 정작 뼈저리게 느끼는 것은 5.1 채널의 음질향상입니다. 젠투 리눅스를 최적화 쪽으로 바라보게 되는데, 막상 젠투를 써보게 되면 최적화 컴파일 보다는 관리의 유연성을 뼈저리게 느끼게 됩니다. 유지 보수 관리에 있어서 타 배포판을 압도하죠.

emerge -U world

이거 하나면 끝이니까요. 소스 설치 방식도 역시 최적화 그 자체 보다는 유연성에 생명이 있다고 봅니다. 예를 들어서 xorg 설치 할 경우를 생각해보죠. 대부분의 배포판은 외국 기준이라서 볼드체 처리가 되어있지 않습니다. 페도라/수세/맨드레이크 에서 이 문제를 해결 할 수 있습니까? 못 합니다. 설령 할 수 있더라도 매우 번거롭죠.
반면 젠투와 같은 소스 컴파일 방식에서는 패치 파일만 있으면 자기가 직접 패치해도 되고, 누군가 소스 패치를 배포하기만 하면 그걸 다른 사람들이 적용해서 사용하기도 용이합니다. 제 경우에는 소스 설치 쪽 손을 들어주고 싶군요.

저는 집과 연구실의 메인 데스크탑에 모두 젠투만 설치해서 쓰고있는 젠투 사용자며, 소스 컴파일 설치 쪽에 한 표 던집니다.

(서버에 젠투를 사용하지 않고 있는 이유는 단지 ‘개인적으로 원하는 배포판을 깔아도 되는 적당한 사양의 서버가 없기 때문’일 뿐입니다. 최근에 연구실에 제가 OS를 고를 수 있는 서버가 딱 한 대 생겼었는데, 별다른 잡동사니 툴 설치가 필요 없는 웹/메일 전담 서버였을 뿐더러, 주어진 시간이 촉박했던 것에 비해 도저히 느긋하게 컴파일할 수 없는 극악무도한 사양이었기에 부득이 FreeBSD를 깔았습니다. 조금만 사양이 더 좋았거나 초기설치와 세팅에 쓸 수 있는 시간이 많이 주어졌었다면 단연 젠투를 깔았을겁니다.)

만일 제가 지금 젠투 사용자가 아니고 레드햇 계열 사용하자라고 하더라도, 아마도 SRPM을 rebuild해서 설치하는 방법을 고수했을 것 같습니다. 다만, 이 글타래에서 이미 여러번 이야기된 바와 마찬가지로, 제가 소스 컴파일 설치를 선호하는 이유는 최적화보다는 유연성과 호환성 때문입니다. 게다가, 정태영님 말씀처럼, 스크래치 방식으로 직접 컴파일하는 것에 비해 젠투의 포티지 시스템은 편리함 측면에서도 상상을 초월합니다. :)

유연성이란 곧 자유로움을 의미합니다.

예를 들어 mc를 설치할 경우, 이 프로그램은 컴파일 옵션에 따라 유니코드나 nls, ncurses 등등을 지원할 수도 있고 안할 수도 있습니다. 어떤 프로그램은 컴파일 옵션에 따라 gtk2가 입혀지기도하고 tcl/tk가 입혀지기도 하죠. (꼭 젠투가 아니더라도) 소스를 컴파일해서 설치해야만 이런 수많은 옵션들을 제 입맛과 필요에 딱 맞게 조절해서 설치할 수 있죠. 바이너리를 가져와 설치할 때에는 컴파일한 상태 그대로를 울며 겨자먹는 심정으로 그냥 써야합니다. 개인적인 취향 상 이건 용납할 수 없습니다. :)

호환성이란 간단히 말해서 ‘오류와 충돌이 없다’는 뜻입니다.

예전에 수 년 동안 레드햇 계열을 쓰던 시절에는, 일단 설치 과정에서 의존성 오류가 끝없이 이어지는건 기본이고, 어찌어찌 해결해서 설치하더라도 결국 프로그램 실행중에 별 잡다한 오류가 다 등장하곤 했었습니다. 그나마 기본 배포판에 들어있거나 온라인 업그레이드로 받은 바이너리는 이런 런타임 오류가 상당히 덜하긴했지만, 종종 최신 기능이 꼭 필요해서 스스로 업그레이드 패키지를 바이너리로 받아서 설치하면 십중팔구 실행중에 뻗어버리곤 했습니다. 당시에는 그냥 그러려니 했었는데, 지금와서 생각해보면 너무 당연한 결과였을 뿐더러 해결책도 명백한 일이었습니다. 패키지 배포자가 바이너리 패키지를 동적으로 컴파일할 당시 사용한 라이브러리와 제 기계에 설치되어있는 라이브러리가 완전히 같을리 만무하니까요.

반면에 소스를 가져다가 제 기계에서 빌드할 경우에는 당연히 완전한 궁합이 이루어집니다. 만일 제 기계에서는 컴파일 자체가 안된다면, 차라리 안되는게 낫습니다. 마치 잘 동작할 것처럼 어물쩡 컴파일되어놓고, 실전 투입 후에 (런타임에) 뻑뻑 오류를 뱉으면서 죽어버리느니, 그럴거면 아예 컴파일 자체가 안되는 편이 낫다고 생각합니다. (그러면 보다 근본적인 단계에서 문제를 해결해볼 여지가 생기죠.) 젠투로 노선을 변경한 이후로는 예전 레드햇 시절에 숱하게 경험했던 런타임 오류들을 거의 본 적이 없습니다. 그나마 간혹 컴파일 에러나 런타임 에러가 발생하는 경우도 ACCEPT_KEYWORDS="~x86"으로 무리하게 극최신 소스를 설치하려고 시도한 경우였을 뿐입니다. 안정버전(이라고는 해도 데비안이나 레드햇보다 훨씬 최신판입니다) 소스만 사용하는 한 런타임 오류는 결코 없더군요.

‘소스 컴파일 설치냐 바이너리 설치냐’의 논점에서 조금 벗어난 이야기긴 하지만, 같은 소스 컴파일 설치라고 해도 배포판에 따라서 그 편리함의 차이는 상당합니다.

예를 들어, 이미 젠투의 포티지 시스템을 맛본 지금에 와서는 LFS는 (공부 목적이 아닌 한) 시도해보고싶지 않습니다. 솔직히 소스를 가져다가 일일이 컴파일해서 설치하는 작업은 유지보수 측면에서 불편한 점이 너무 많습니다. 그래서 레드햇 등의 패키지 관리 시스템이 등장한 것이기도 하고, 그런 이유로 저도 슬랙웨어에서 레드햇으로 신나게 갈아탔었죠. 하지만, 젠투를 사용해본 후로는 두 번 다시 젠투를 떠나고싶지 않을만큼 편리하더군요. 위에서 말한 컴파일 옵션 조절 같은 것도 사실은 일일이 설치할 때마다 지정하는게 아니라 (하려면 할 수도 있지만) USE flag라는 것을 한 번 설정해두면 대개 끝입니다. 최신 소스 정보에 동기화하는 것도, 이미 설치된 시스템을 최신 소스와 옵션 설정에 맞게 다시 싹 컴파일하는 것도 대부분 명령 한 방에 끝나니까요.

글타래의 원래 취지 상 굳이 플레임을 피할 필요가 없을 것 같아서 신나게 젠투 자랑을 떠들어놓았지만, 그 중에서 딱 하나만 골라보라고 한다면 역시 호환성입니다. 이제는 (예를들면 오픈오피스 같은) 거대 프로그램조차도 런타임 오류가 전혀 안보이는 것이 너무 당연해져버려서, 간혹 바이너리로 설치된 툴 서버의 프로그램을 사용할라치면 짜증부터 밀려오거든요. :)

부지런한 분들이 많으시네요.

전 데비안 깔아놓고
# aptitude update && aptitude upgrade
.. 만 종종 해줍니다.

귀찮아요. -_-

비 전공자/개발자 입장에서 소스 컴파일은 귀찮고 번거로운 일로 느껴집니다. 전산 관련 쪽 공부를 하고 있다거나 관련 직업이 그쪽 계통인 분은 어떨지 모르겠지만, 단지 리눅스를 도구로써 사용하는 사람 입장에서 소스 컴파일은 시간낭비일 뿐입니다.
물론, 처음 리눅스를 접할 때에는 이것 저것 옵션 바꿔서 컴파일도 해 보고 다른 배포본도 이것 저것 설치해 보게 되지만 그것도 길어야 처음 몇 년입니다. 몇 년 쓰다 보면 결국 귀찮은 작업은 안 하게 됩니다. 실컷 컴파일 해봐야 결국 사용하는건 거기서 거기니까요.

아이참, 그래서 젠투자랑하고 있잖아요~ 8)

그저 사용만 하면 되는분이라도,
문제는 발생할테고, 해결을 해야 하겠지요.

젠투자랑 젠투자랑 :D

제가 관리하는 서버에 하루 방문자가 대충 평일 3만명, 주말 7만명쯤 되는 중간 정도 크기의 업체가 하나 있는데, OS 가 젠투입니다.

CPU 4가 제온 4 개가 박혀 있기 때문에(전임자가 그렇게 박아뒀습니다. HT 켜면 8개로 나옵니다.) 컴파일 이 그다지 힘들거나 하지는 않습니다.

일주일에 한번꼴로 emerge --sync && emerge -upDv world 하고 있습니다. 그다지 부담이 되지는 않습니다. 어차피 서비스 돌리는 것만 안 날리면 되거든요.

거기에 distcc까지 써준다면... :wink:

제가 관리하고 있는 사이트는 대략 하루 unique 접속자가 35 ~ 40만 정도 되는데 거의 모든 서버를 젠투로 관리합니다. 레드햇 7.3에서 올해 젠투로 이전하여 거의 다 이전하였습니다.

서버이기 때문에 x나 그밖의 desktop 환경을 갖추지 않아도 되기 때문에 설치하는데 그리 시간이 많이 들지는 않습니다.

젠투를 사용해서 편리한 점은 아파치 등을 패치하여 사용할 때 관리가 편하다는 점입니다. srpm을 바탕으로 소스를 패치하여 rpm을 만드는 것보다 젠투의 ebuild를 고치는 것이 훨씬 쉽습니다.

앞서 많은 분들이 지적해 주셨지만 소스 기반 패키지 시스템의 장점은 성능 보다는 유연하고 일관된 관리가 가능하다는 데 있는 것 같습니다.

이 쓰레드를 읽다보니 확실히....

젠투가 젤 좋은 배포판이라고는 할 수 없지만 ... 젠투는 사용자들에게 큰 만족감을 주는 배포판이란 걸 알겠군요 ;)

소스설치로 인해 보안상 이점이 생기기도 합니다.

보통 보안 취약점이 발표되면 몇몇 사람들에 의해 이를 공격하기 위한 스크립트들이 만들어지게 되는데, 이런 취약점이 바이너리에 종속적인 경우 대형스크립트들은 많이 쓰이는 바이너리 배포판(ex. debian, redhat)을 위주로 작성된다고 합니다.

제가 보아왔던 많은 문서들이 추가 기능의 지원 다음으로 저런 이유를 많이 꼽으면서, 웹서버 구축시에는 적어도 apache, php, mysql정도는 소스컴파일을 추천한다고 언급하고 있었습니다.

하드웨어를 무작정 늘리는것또한 회사입장에서는 손해 입니다.
그만큼 편해지기 위해서 그만한 비용이 매달 더 마니 지출이 되니깐 말입니다.

일예로 튜닝을 통해서 10대가 할일을 바이너리로 20대라고 했을때 이를 1년간 IDC에 넣어두고 사용한다고 할때, 이경우 IDC비용이 대당 매달 20만원이라고 할때 10대 일경우 200만원, 20대일경우 400만원 입니다.
또한 부수적인 장비로 허브 12포트가 아닌 24포트를 구입해야 될테고, 관리 및 개발에 따른 인건비또한 상당히 많이 들어갈 것입니다.

거기에 시스템의 노말상태(바이너리설치)의 경우 바이너리 배포자들이 악의적으로 백도어를 심었을경우에 따른 크래킹사고(실제로 이러한 사건이 있었습니다.)가 있을수 있습니다.

문론 소스파일을 받아서 직접적인 configure 등을 통한 작업을 할시에 그에 따른 셋팅에 들어가는 초기 시간 및 비용, 그리고 관련 어플리케이션간의 의존성등을 해박하게 알아야 되는점이 있습니다만, 시스템엔지니어 혹은 관리자라면 알아야 되는게 아닐까요? (그렇다고 저도 해박하게 아는건 아닙니다만...) 만약 위와 같은 핑계를 된다면 그사람은 시스템관리자의 필요성을 모르는것이거나 한것이 아닐까? 생각이 듭니다.

문론 젠투라고 해서 아주 완벽한 최적화는 힘들다는거 저도 인정합니다.(아직까지 젠투도 너무나 세세한 CFLAGS 는 오히려 시스템 설치에 오류가 많더군요.)

그래도 저는 제가 설치한 패키지(소스)에 대한 최소한 로그등이 남아 있는 젠투가 그래도 시스템에 맞게 어느정도까지 최적화 된다는것에 대해서 극히 옹호 합니다.
(AMD64 시스템단도 예전과는 틀리에 매우 많이 안정화 되었답니다~)

한가지 예를 더 들면, 옵테론 듀얼 시스템에 레드헷 엔터프라이즈 4 버젼을 설치시 대략 20분정도 걸린다고 볼때(실제 설치 해본적은 없음), 젠투는 동일 시스템에 약 3시간 정도 걸립니다.

2시간 40분을 더 투자해서 80%성능을 쓰는것이 좋을까요? 20분만 투자해서 40-50% 성능을 쓰는것이 좋을까요?

거기에 레드헷의 경우 필요 없는 패키지를 지운다고 그 지우는 작업을 하게 된다면, 거기에 들어가는 시간만 해도 더욱 마니 걸릴지도 모르겠군요.

참고로 젠투는 처음부터 기본적인 시스템 파일 말고는 다 일일히 설치해야 되므로 시작부터 끝까지 셋팅이 젠투는 3시간이면 끝난다고 볼때 레드헷은 20분+알파 가 되겠지요...

문론 유연함에 관련된 내용은, 위에 다른분의 글타레가 매우 자세히 써있으니 그부분은 생략 했습니다. ^^

"유연성" 이라고 하셨는데 소스 컴파일 설치가 바이너리 설치보다 특별하게 "유연" 하다고는 생각지 않습니다. 유연성 뿐만이 아니라 생산적인 면, 그리고 효율적인 면을 볼때 매번 설치할때 마다 몇시간 동안 컴파일 하는걸 지켜봐야하는 것은 생산적인 면에서나 효율적인 면에서나 뒤떨어진다고 봅니다. 단순히 컴파일 옵션을 설정하는 것이 "유연" 하다는 것이라면 개인보다는 그 시스템을 만든 개발자들이 컴파일 한 것이 더 자세한 옵션과 필요한 옵션을 알고 더 "유연" 하게 만들지 않았을런지요? 대표적인 예로 mysql 이 있겠군요.

님 주장을 정리하면.

1. 소스 컴파일 방식이 바이너리 설치보다 특별히 유연하지 않다고생각한다.
2. 유연성, 생산성, 효율성 모두를 고려해 볼 때 설치할 때 마다 컴파일 하는 걸 기다려야하는 건 생산성이나 효율성이 떨어진다
3. 단순히 컴파일 옵션을 설정하는 것이 유연하다는 것이면, 개인보다 그 시스템을 만든 개발자가가 컴파일 한것이 더 유연할 것이다.

제가 드리고 싶은 말씀은 대체 님께서 무슨 말씀을 하시고 계신지 모르겠다는 것입니다.

바이너리 설치가 컴파일 설치보다 유연성이 떨어지지 않는다고 주장하고 계시지만, 그 주장에 대해서 아무런 근거도 제시하고 있지 않습니다.

"유연성 뿐만 아니라" 라는 말로 시작하지만, 정작 바이너리 설치가 유연성을 가지고 있다는 근거도 없습니다.

마지막 주장은 더더욱 황당합니다. "단순히 컴파일 옵션을 설정"하는 것이 유연하다면, 제작자는 그 프로그램에 대해 잘 알테니 그 옵션을 잘 설정해서 더 유연하게 컴파일 해서 패키지로 배포할 수 있다는 말씀인 것 같은데, 여기서는 거의 유연성이라는 말의 의미는 고려하지 않고 무슨 유연성이 단순 성능처럼 컴파일 옵션 설정 잘하면 향상될 수 있는 능력치로 보고 계신 것 같습니다. 대체 mysql 패키지가 mysql 소스 tarball 보다 어떻게 유연할 수가 있습니까? 소스 설치를 지지하시는 분께서 말씀하시는 유연성을 사용자가 선택할 수 있는 것이 많다는 의미인데, 소스 컴파일 시 옵션의 선택권을 사용자에게 줄 수 없는 패키지 시스템이 어떤 유연성은 더 가지고 있다는 것인지에 대해서 밝히셔야 제대로 된 논지가 될 것 같습니다.

제가 생각하기에 님의 주장은 "바이너리 패키지는 소스 컴파일 할 시간이 적어서 효율적이고 생산적이다" 라는 주장을 동어 반복 하고 계신 것 같습니다. 아무리 봐도 유연성에 대해서 판단을 내린 부분은 단 한 군데도 없습니다.

mysql 을 얘기하셨으니 mysql 예로 대답해드리겠습니다 :)

소스를 가져다가 직접 빌드한다면 "원하는 것들만"을 지원하도록 빌드할 수 있으니 "유연하다" 라고 할 수 있겠지만...

개발자들이 컴파일해서 제공하는 것은 (MAX와 그냥 이렇게 두가지로 배포되죠?) 모든 옵션들과 위치등이 모두 "고정"되어 있는 버젼입니다... 이런게 더 "유연하다" 라고 생각되지는 않는군요 ;)

아래는 젠투에서 mysql 을 설치하기 전에 어떤 플래그로 설치가 되는지를 확인해본 모습입니다...

bdb 를 사용하고 싶다면 berkdb 플래그로 해당 옵션을 활성화시킵니다...
minimal 옵션과 함께라면 innodb, benchmark 등의 기능들이 빠지구요

뭐 다른 옵션들도 대강 보면 어떤 역할을 할 지 알 수 있습니다 :)
저런 간단한 플래그 변경으로 내가 원하는 것들만 활성화가 가능합니다... 물론 직접 소스를 가져다가 옵션을 넣고 빌드하는 것만큼은 유연하지 못하겠지만... 바이너리 설치에 비해서는 훨씬 유연하다 라고 말할 수 있습니다...

php 는 한 수 더뜨죠 --;;

이 글타래에서 젠투 이야기는 좀 빼고 진행했으면 좋겠군요.

젠투가 좋다는건지 소스 설치가 좋다는건지 경계가 모호해지는 것 같습니다. (타 배포판에서의 예가 거의 나오질 않고 있네요)

두 배니까 200%죠?

"프로그램 하나"만 생각한다면 다시 컴파일 하는 것 만으로 200%의 성능 향상을 거둔다는 것은 좀 황당하죠. 물론 비교대상을 좀... 황당하게 잡으면 가능할 수도 있겠지만요. 가령, MMX지원을 빼고 컴파일한 버전과의 비교랄지...

그런데 200% 까지는 아니더라도 현존하는 배포본 상황을 기준으로 본다면 개별 프로그램 단위에서 의미있는 수준의 성능향상이 충분히 가능합니다.

실제로, 몇달 전에 "동영상 자동 변환"과 관련된 조사 과정에서 사용되었던 debian 배포본을 통하여 설치된 버전의 소프트웨어와 같은 기계에서 새로 컴파일한 버전의 성능차이는 150% 이상이었습니다. (조사가 중단되는 바람에 정확한 수치는 기록으로 남아있지 않습니다만...)

그런데, 이런 최적화가 한 프로그램에 대해서만 적용된 것이 아니라 관련된 시스템 상당 부분에 걸쳐 적용되었을 경우, 그리고 목표로 하는 작업이 상당히 성능에 대한 의존도가 높을 경우, 충분히 200% 이상의 성능향상을 볼 수 있을 것입니다.

덧붙여서, 성능이 중요한 시스템이라면 당연히 최적화 과정을 거쳐야 할 것입니다. 다만, 제 경우라면 "한 번의 최적화와 패키징, 그리고 만들어진 패키지를 이용한 편리한 복제"의 방식을 사용합니다.