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

GunSmoke의 이미지
GunSmoke의 이미지

순선님도 그렇고 요즘은 KLDP에서 troll, flame 전쟁에 대한 제한도 많이 완화된 듯 합니다. 이에 논쟁거리 하나를 던지고자 합니다. (많이 낚이길 기대합니다)

늦은 감이 있지만 제라드 무라니의 security and optimization을 읽고 있습니다. 모든 패키지를 소스 파일을 이용해서 일일이 컴파일 옵션을 최적화해서 설치하는 과정을 소개한 무라니의 노력이 안스럽기 짝이없네요.

개인적으로 더욱 좋아지고 있는 하드웨어 환경에 비추어볼때 이같은 최적화는 비생산적이라고 생각합니다. 소스 파일을 받아와서 컴파일하여 설치하는 방법은 바이너리 설치를 통해서 손쉽게 설치할 수 있는 것에 비해 잃을게 많다고 생각하는데 여러분은 어떻게 생각하십니까?

특정 배포판의 패키지 관리 방식에 대한 논의도 허용하고자 합니다. 본문에서도 알 수 있듯이 저는 젠투 리눅스 회의론자입니다.

大逆戰

bear의 이미지

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

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

GunSmoke의 이미지

bear wrote:

그런데, 만약에 서버의 행동을 해야 한다면, 조금이라도 포퍼먼스를 생각해야 한다면, 한명의 접속자라도 더 늘려야 하는 경우가 발생한다면...

서버의 행동(?)과 퍼포먼스의 향상을 위해서 어렵게 최적화하는 시간을 들이는 노력보다 메모리를 증설하거나 CPU를 교체하는 비용을 들이는 것이 더 생산적이라고 생각합니다.

ps. 본문에서 밝혔듯이 플래임워를 위한 글타래입니다. 선택은 오직 흑과 백에서, 중간은 없습니다. :D

大逆戰

maindb의 이미지

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

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

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

죠커의 이미지

GunSmoke wrote:
bear wrote:

그런데, 만약에 서버의 행동을 해야 한다면, 조금이라도 포퍼먼스를 생각해야 한다면, 한명의 접속자라도 더 늘려야 하는 경우가 발생한다면...

서버의 행동(?)과 퍼포먼스의 향상을 위해서 어렵게 최적화하는 시간을 들이는 노력보다 메모리를 증설하거나 CPU를 교체하는 비용을 들이는 것이 더 생산적이라고 생각합니다.

ps. 본문에서 밝혔듯이 플래임워를 위한 글타래입니다. 선택은 오직 흑과 백에서, 중간은 없습니다. :D

구글의 경우 커스터마이징한 OS를 사용하고 있습니다. 그리고 그들이 최초로 시작했던 것도 하드웨어에 비싼 돈을 투자하는 것 보다는 항상 비용 문제가 심각했던 것 만큼 가지고 있는 하드웨어 자원을 최대한 활용하는 것이 필수적이었습니다.

소프트웨어와 하드웨어 모두 투자해야 하는 대상이라고 생각합니다. 하지만 컴파일 하는 것이 투자의 방법이라고는 생각하지 않습니다. :-)

doldori의 이미지

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

ssggkim의 이미지

예전에 redhat을 좀 쓰다가, 한동안 한참 linux와는 떨어져 있다가, 요즘 한 1년여정도 gentoo를 쓰는데 예전에 겪었던 dependency문제는 경험하지 못했습니다.
요즘 fedora는 어떤지 모르겠군요. :twisted:

정태영의 이미지

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

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

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

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

오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...

http://mytears.org ~(~_~)~
나 한줄기 바람처럼..

warpdory의 이미지

배포판 정책을 따릅니다.

데비안이나 레드햇 계열 (deb, rpm 설치...)은 아주 특별한 경우가 아니면 배포판에서 지원하는 패키지로 깔고..
젠투는 emerge 로 컴파일 해버립니다. (오픈오피스 같은 경우는 너무 오래 걸려서 바이너리 설치합니다만...)


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

즐겁게 놀아보자.

voljin의 이미지

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

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

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

wish의 이미지

실용적인 관점에서는 바이너리 설치가 낫다고 봅니다. 요즘처럼 기가 급 씨피유와 기가 급 램 테라 급 하드디스크를 소유하는 데 큰 어려움이 없는 상황에서 효율성을 위한 소스 컴파일은 예전 보다 의미가 없습니다.

그러나 유닉스 시스템을 가지고 놀아본 사람들은 누구나 느끼시겠지만, 유닉스 상에서 패키지 시스템은 그다지 깨끗하다는 느낌이 들지를 않습니다. 많은 유닉스 소프트웨어들은 컴파일 시 여러 선택권을 사용자에게 줍니다. 이걸 바이너리 패키지로 배포하려다 보면, 먼가 덕지덕지 붙는 다는 느낌을 지울 수가 없습니다.

예를 들어, vim 의 경우 컴파일 옵션에 따라서 gtk2, 그놈까지 의존성이 붙습니다. 이 걸 패키지로 배포하려면, 각 컴파일 옵션별로 패키지를 다 따로 만들 수 밖에 없습니다. 그렇지만 소스 기반 플랫폼(gentoo 나 bsd 의 포트들, 혹은 그냥 tarball)은 하나의 파일만 배포하고 옵션으로 조정할 수가 있습니다.

그래서 수 많은 "결벽증" 증세가 있는 사람들이 emerge 나 port 를 좋아하는 것입니다. 이건 유닉스 시스템의 전통 때문에 생겨 난 것이라고도 생각합니다. 일반적으로 이전부터 유닉스는 소프트웨어를 소스 자체로 배포했었고, 따라서 컴파일 시 수도 없는 옵션들을 붙이게 된 것이고, 이런 전통 위에서 "깔끔한" 시스템을 만들기 위해서는 소스 기반의 시스템이 좋았다고생각합니다 .

소스 컴파일이 가져오는 성능 상승 효과는 매우 미미하겠지만, 그렇다고 소스 기반 배포본이 의미 없는 것도 또한 아닙니다. 유닉스의 특성상 소스 기반 배포본이 좀 더 깔끔하고 유연하다는 느낌은 지일 수가 없습니다. 물론 apt-get 이나 yum 같은 패키지 관리 시스템의 편함과 빠름도 무시 할 수 없습니다.

그리고, 대부분의 패키지 기반 배포본에서도 소스 컴파일을 통해 패키지를 만들 수 있고, 소스 기반 배포본도 대부분 바이너리 파일을 패키지 단위로 묶기 때문에 사용하기 나름입니다. 다만 어디에 주안점을 두고 있고, 그에 따라 주된 사용방법이 다르게 나타나는 것 뿐입니다.

debian 을 쓰면서 일일이 apt-src 로 소스를 가져다가 컴파일 해서 쓰는 것도 우스은 이야기일 것이고, gentoo 를 쓰면서 패키지 파일 받아다가 시스템을 구축하는 것도 좀 어색할 것입니다.

결론은 상황과 취향에 따라 다르다.. 가 아닐지요 ;;

ssggkim의 이미지

wish wrote:
실용적인 관점에서는 바이너리 설치가 낫다고 봅니다. 요즘처럼 기가 급 씨피유와 기가 급 램 테라 급 하드디스크를 소유하는 데 큰 어려움이 없는 상황에서 효율성을 위한 소스 컴파일은 예전 보다 의미가 없습니다.

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

warpdory의 이미지

ssggkim wrote:
wish wrote:
실용적인 관점에서는 바이너리 설치가 낫다고 봅니다. 요즘처럼 기가 급 씨피유와 기가 급 램 테라 급 하드디스크를 소유하는 데 큰 어려움이 없는 상황에서 효율성을 위한 소스 컴파일은 예전 보다 의미가 없습니다.

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

그런데, 사실 그 몇몇 패키지가 좀 문제가 되죠.. 특히 오픈오피스나 불여우, mplayer 플러그인 등등 -_- 잠들기 직전에 emerge 시켜 놨는데.. 중간에 에러 나서 아침에 일어나서 모니터를 켜보니 프롬프트가 멀뚱 거리며 껌뻑 껌뻑 하면 ... 좀 짜증나더군요.


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

즐겁게 놀아보자.

sandro의 이미지

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

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

無心

ssggkim의 이미지

warpdory wrote:
ssggkim wrote:

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

그런데, 사실 그 몇몇 패키지가 좀 문제가 되죠.. 특히 오픈오피스나 불여우, mplayer 플러그인 등등 -_- 잠들기 직전에 emerge 시켜 놨는데.. 중간에 에러 나서 아침에 일어나서 모니터를 켜보니 프롬프트가 멀뚱 거리며 껌뻑 껌뻑 하면 ... 좀 짜증나더군요.

ACCEPT_KEYWORD 를 testing에서 stable로 바꾸고 나서는 그런적이 거의 없었던걸로 기억합니다만...
package 갱신이 좀(많이?) 느리긴 하죠.

yuni의 이미지

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

==========================
부양가족은 많은데, 시절은 왜 이리 꿀꿀할까요?
=====================
"지금하는 일을 꼭 완수하자."

hey의 이미지

소스 기반 패키징 시스템에서 컴파일 옵션이 새로운 것이면 컴파일 해서 중앙 서버에 올려놓고, 이전에 이미 있었던 것이면 자동으로 서버에서 가져다 깔면 어떨까요? :]


----------------------------
May the F/OSS be with you..


jachin의 이미지

hey wrote:
소스 기반 패키징 시스템에서 컴파일 옵션이 새로운 것이면 컴파일 해서 중앙 서버에 올려놓고, 이전에 이미 있었던 것이면 자동으로 서버에서 가져다 깔면 어떨까요? :]
소스 코드 컴파일이 비생산적인 방법이라고 할 수 있지만, 생산적인 방법을 통해서 하면 어떨까 생각합니다.

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

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

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

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

sheep의 이미지

전에 레드햇이나 페도라 쓸 때에는 가끔 소스 받아서 컴파일할 때가 많았습니다..

지금은 우분투 쓰고 거의 소스 컴파일은 안하게 되네요...

귀차니즘의 압박이라고 할까요...

gnomesword랑 sword는 소스 받아서 컴파일했습니다...

--------
From Buenos Aires, Argentina
No sere feliz pero tengo computadora.... jaja
닥치고 Ubuntu!!!!!
To Serve My Lord Jesus
blog: http://sehoonpark.com.ar
http://me2day.net/sheep

루시퍼666의 이미지

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

세상밖에서 나를 보기~!!

advanced의 이미지

제가 생각하기로는 젠투의 패키지 시스템의 목적은
소스 설치가 핵심이 아니고 소스로 설치 할때 처럼
옵션을 사용자가 정하는것입니다

그런면에서 볼때 젠투의 패키지 시스템은 몇가지 면에서
메우 매력적입니다

또한 비공식 패치등도 개인적으로 적용시켜 설치하기도
수월합니다. 그리고 이런식으로 설치된 패키지 조차도
패키지 시스템으로 관리가 가능합니다

만약 데비안이나 페도라등등의 바이너리 기반 배포판들이라면
이런 경우에 일일이 소스컴파일 해야하는 정말 귀찮은 작업을
수행해야 하며 나중에 제거시 난감해지기도 합니다

hey의 이미지

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


----------------------------
May the F/OSS be with you..


googlejoa의 이미지

advanced wrote:

만약 데비안이나 페도라등등의 바이너리 기반 배포판들이라면
이런 경우에 일일이 소스컴파일 해야하는 정말 귀찮은 작업을
수행해야 하며 나중에 제거시 난감해지기도 합니다

젠투에서는 저런 귀찮은 작업을 하지 않아도 된다는 말씀이신가요?
제가 잘 몰라서요.

vacancy의 이미지

advanced wrote:
만약 데비안이나 페도라등등의 바이너리 기반 배포판들이라면
이런 경우에 일일이 소스컴파일 해야하는 정말 귀찮은 작업을
수행해야 하며 나중에 제거시 난감해지기도 합니다

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

advanced의 이미지

googlejoa wrote:
advanced wrote:

만약 데비안이나 페도라등등의 바이너리 기반 배포판들이라면
이런 경우에 일일이 소스컴파일 해야하는 정말 귀찮은 작업을
수행해야 하며 나중에 제거시 난감해지기도 합니다

젠투에서는 저런 귀찮은 작업을 하지 않아도 된다는 말씀이신가요?
제가 잘 몰라서요.

젠투에서는 설치 과정을 자신이 수동으로 부분 부분 진행 할 수 있습니다

예를 들어

ebuild foo.ebuild unpack

를 하면 패키지들이 압축만 풀립니다

그리고 압축이 풀린 디렉토리로 가서 패치를 한후 또는 자신이 직접 소스를 수정한후

ebuild foo.ebuild compile

위의 커맨드로 컴파일만 할 수 도 있고
ebuild foo.ebuild merge

위와 같이 하면 컴파일이 되어 있다면 설치가 되며, 컴파일이 되지 않은
소스라면 컴파일과 설치가 순서대로 수행됩니다

일반 패키지와 동일하게 설치되기 때문에 업데이트나 제거에
전혀 기타 작업이 필요 없습니다.

또한 기타로 /usr/local/portage 같은 곳에 임의로
자신이 패키지를 직접 작성하거나 비공식 패키지등을 넣어두고
설치하고 할 수 도 있습니다.

khris의 이미지

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

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

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

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

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

───────────────────────
yaourt -S gothick elegant
khris'log

leanblue의 이미지

젠투 쓰시면 신경쓰실 거 별로 없습니다.

필요한 패키지가 다 깔렸다면,

emerge sync 와 emerge -uva world 만 기억하시면 됩니다.

가끔 etc-update 라는 난관이 오긴 하지만

제가 젠투를 쓰는 이유는 쉬워서, 귀찮아서

(적응되면 다른거 쓰기 싫어집니다.)

(물론 컴파일 시간의 압박은 있죠-_-; )

LeanBlue in CyberWorld!!!

욱성군의 이미지

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

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

advanced의 이미지

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

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


소스 설치와 바이너리 설치 비교의 대상은
최적화가 아닙니다. 제가 위에 써 놓은 글처럼
'패키지 설치에 있어서의 유연함' 입니다

다른 젠투 사용자들은 모르겠지만 저는 이런 관점으로
소스 설치를 선호하고 있습니다

송효진의 이미지

젠투의 존재로 인해
고사양 하드웨어 '서버' 에서 바이너리 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

하면 cdb 파일이 자동생성 됩니다.
ssl key 파일 생성하는 mkservercert 도 젠투개발진이 만든것입니다.

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

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

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

욱성군의 이미지

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

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


소스 설치와 바이너리 설치 비교의 대상은
최적화가 아닙니다. 제가 위에 써 놓은 글처럼
'패키지 설치에 있어서의 유연함' 입니다

다른 젠투 사용자들은 모르겠지만 저는 이런 관점으로
소스 설치를 선호하고 있습니다

패키지 설치에 있어서의 유연함은 바이너리 쪽이 더 높지 않나 생각됩니다. 의존성을 해결하는 시간이 소스 컴파일하는 시간보다 훨씬 짧고, 설치시간도 굉장히 짧으니 그만큼 빨리 설치할 수 있지요. 그게 바로 유연성이 아닐까 생각됩니다.

ssggkim의 이미지

garderisia wrote:

패키지 설치에 있어서의 유연함은 바이너리 쪽이 더 높지 않나 생각됩니다. 의존성을 해결하는 시간이 소스 컴파일하는 시간보다 훨씬 짧고, 설치시간도 굉장히 짧으니 그만큼 빨리 설치할 수 있지요. 그게 바로 유연성이 아닐까 생각됩니다.

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

leanblue의 이미지

패키지 설치가 유연하단건 원하는 것 만 골라 깔 수 있다는 얘기지요

젠투의 경우 다양한 USE flag가 있어서

USE flag에 걸린 의존성을 체크를 통해

같이 설치되는 패키지들을 취사 선택해줄 수 있습니다.

note ~ # emerge mplayer -pv

These are the packages that I would merge, in order:

Calculating dependencies ...done!
[ebuild   R   ] media-video/mplayer-1.0_pre7  -3dfx -3dnow -3dnowext +X -aac -aalib +alsa (-altivec) -arts -bidi -bl -cdparanoia -cpudetection -custom-cflags -debug -dga -directfb -divx4linux -doc +dts -dv -dvb +dvd -dvdread -edl +encode +esd -fbcon -ggi +gif +gtk -i8x0 +ipv6 -jack -joystick +jpeg -libcaca -lirc +live -lzo +mad -matroska -matrox -mmx -mmxext -mythtv -nas +nls -nvidia +opengl +oss +png +real -rtc +samba +sdl -sse +sse2 +svga -tga -theora +truetype -v4l -v4l2 +vorbis +win32codecs -xanim -xinerama +xmms +xv -xvid -xvmc 7,621 kB

Total size of downloads: 7,621 kB

뒤에 붙어있는 것들이 USE flag입니다.

소스 설치시에는 필요한 것들만 골라 깔 수 있지만

바이너리 패키지 제공자가 특정 코덱을 포함시키지 않고 깔았다고 한다면

원하는 형태로 패키지된 바이너리를 찾거나 소스 설치를 해야겠죠.

LeanBlue in CyberWorld!!!

pool007의 이미지

ssggkim wrote:
예전에 redhat을 좀 쓰다가, 한동안 한참 linux와는 떨어져 있다가, 요즘 한 1년여정도 gentoo를 쓰는데 예전에 겪었던 dependency문제는 경험하지 못했습니다.
요즘 fedora는 어떤지 모르겠군요. :twisted:

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

gcc.i386 base

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

--
Passion is like genius; a miracle.

까나리의 이미지

장단점은 있습니다.

젠투로 예를들면 , 만약 수십대에 서버에 적용을 해야한다~

distcc 같은걸로 분산컴파일 해버리면 됩니다.

허나, 저는 바이너리가 좋습니다. =3

아빠곰의 이미지

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

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

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

----
아발발다빠따반반나다발딸발발다빠따따맣밤밤따받따발발다따밝다발발다빠따따밤반다빠따다맣밥발
발다따밥다발발다따박다발발다빠따따밞밭밭다따다맣아희

정태영의 이미지

제가 젠투를 사용하지 않았었다면...

gtk2 초기 시절에... 파일셀렉터 패치 (종류가 두가지 있었습니다) 를 미리 이것 저것 적용시켜보지도 못했을 거고... gimageview 의 듀얼헤드 관련 문제를 해결하지도 못했을겁니다 ... glib 에 제 멋대로 이상한 패치를 만들어넣지도 않았을거고 xchat nick completion 관련된 해킹도 아마 못했을거라고 생각합니다...

그냥 단순하게...

Quote:
# ebuild /usr/portage/net-irc/xchat/xchat-2......ebuild unpack
# cd /var/tmp/portage/xchat-2.../work/xchat/src/
# vi 뭐시기 뭐시기 뭐시기
# make
반복...
# ebuild /usr/portage/net-irc/xchat/xchat-2......ebuild merge

등의 간단한 커맨드를 통해 소스 패치... 언팩... 그리고 해킹... 후 컴파일.. 설치... 를 모두 할 수 있었습니다... 직접 소스를 해킹할 수 있는 능력이 있다면... 젠투만큼 이상적인(?) 플랫폼은 없다고 봅니다 ...

X 볼드패치 관련해서도 그랬구요 :p
(나름대로 X 볼드패치를 첨 알렸던 사람이라고 생각하는데 말이죠 꺄홋~)

얼리어답터라거나... 새로운 것에 대한 호기심이 많은 경우라면 소스 를 컴파일해서만 얻어질 수 있는 이득이 꽤있다는 점은 사실입니다 :twisted:

오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...

http://mytears.org ~(~_~)~
나 한줄기 바람처럼..

CY71의 이미지

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

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

emerge -U world

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

송효진의 이미지

점점 젠투 vs 비젠투 의 전쟁이 되어가는군요. :twisted:

차리서의 이미지

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

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

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

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

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

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

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

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

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

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

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

--
자본주의, 자유민주주의 사회에서는 결국 자유마저 돈으로 사야하나보다.
사줄테니 제발 팔기나 해다오. 아직 내가 "사겠다"고 말하는 동안에 말이다!

무우의 이미지

debian 바이너리를 CELL(PS3) 데스크탑에 설치하면 좋겠습니다.
아마 2006년 중반에

vacancy의 이미지

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

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

귀찮아요. -_-

codebank의 이미지

시간이 많을 때(덜 귀찮을때)는 소스컴파일 설치를하고 시간이 없을때(귀찮을때)는
바이너리 설치를 합니다.

하지만 바이너리를 지원하지 않을경우에는 소스컴파일 설치만이 유일한 대안이더군요.(당연한가??? :))

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

alee의 이미지

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

아빠곰의 이미지

아, 이 글타래를 관심있게 보고있습니다. 또하나의 플레임 토픽이 만들어진건가요 :twisted:

alee님 말씀처럼, end user입장에서 리눅스란거 몇해 쓰다보면, 다 그게그거고, 대충 편하게 설치할 수 있는것 찾아쓰면 되는것 같이 생각되더군요. 귀찮잖아요. :oops: 그래서인지 한동안 데비안에 열광하던 분들이 많았습니다. 닭도 까는 데비안! Believe dselect!

그래도, 몇몇 경우; 예를 들어 관심있는 프로그램의 새 릴리즈가 나온경우엔, 소스설치 외에는 빨리 체험해 볼 방법이 없습니다. 많은 프로그램들이 바이너리 패키지인 deb와 rpm보다는 tar.gz로 된 소스파일을 제공하니까요. 바이너리 패키지 사용자들이 새 버전을 써보기 위해서는, 패키지를 컴파일하고, 다른 프로그램과 충돌은 없는지 확인하는 절차를 거쳐서 비교적 늦게 제공됩니다. 그러니, 소스를 직접 가져다 설치하는것이 가장 빨리 체험할 수 있는 방법이 되고, 자주 이용하게 되더군요.

----
아발발다빠따반반나다발딸발발다빠따따맣밤밤따받따발발다따밝다발발다빠따따밤반다빠따다맣밥발
발다따밥다발발다따박다발발다빠따따밞밭밭다따다맣아희

송효진의 이미지

alee wrote:
비 전공자/개발자 입장에서 소스 컴파일은 귀찮고 번거로운 일로 느껴집니다. 전산 관련 쪽 공부를 하고 있다거나 관련 직업이 그쪽 계통인 분은 어떨지 모르겠지만, 단지 리눅스를 도구로써 사용하는 사람 입장에서 소스 컴파일은 시간낭비일 뿐입니다.

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

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

젠투자랑 젠투자랑 :D

voljin의 이미지

젠투를 소스 컴파일로 쓸 수 있는 것은 소규모 비지니스, 학생, 개인의 홈 정도가 아닐지...

CPU time이 공짜가 아니게 되면 역시 힘들지 않나요?

warpdory의 이미지

voljin wrote:
젠투를 소스 컴파일로 쓸 수 있는 것은 소규모 비지니스, 학생, 개인의 홈 정도가 아닐지...

CPU time이 공짜가 아니게 되면 역시 힘들지 않나요?

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

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

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


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

즐겁게 놀아보자.

정태영의 이미지

voljin wrote:
젠투를 소스 컴파일로 쓸 수 있는 것은 소규모 비지니스, 학생, 개인의 홈 정도가 아닐지...

CPU time이 공짜가 아니게 되면 역시 힘들지 않나요?

비슷한 사양과 거의 같은 옵션으로 여러대를 설치하는거라면 오히려 유리합니다...

젤 사양 좋은 녀석을 빌드머신을 하나 잡고 portage tree 등은 한 대에서 관리를 하면 됩니다. -B 옵션으로 바이너리 패키지 를 만든 후...

나머지 서버들에서는 nfs 등으로 portage 디렉토리를 마운트 한 다음에 emerge --use-pkg-only world 등의 방법을 통해서 업데이트 하면 되니까요 :)

오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...

http://mytears.org ~(~_~)~
나 한줄기 바람처럼..

ssggkim의 이미지

정태영 wrote:

비슷한 사양과 거의 같은 옵션으로 여러대를 설치하는거라면 오히려 유리합니다...

젤 사양 좋은 녀석을 빌드머신을 하나 잡고 portage tree 등은 한 대에서 관리를 하면 됩니다. -B 옵션으로 바이너리 패키지 를 만든 후...

나머지 서버들에서는 nfs 등으로 portage 디렉토리를 마운트 한 다음에 emerge --use-pkg-only world 등의 방법을 통해서 업데이트 하면 되니까요 :)

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

voljin의 이미지

음..본질적으로, 젠투를 쓰면서도 바이너리 설치는 가능하니 젠투가 좋다 안좋다 보다는 소스 컴파일로 얻고 버리는 득실을 이야기하는게 주제가 명확해질 것 같네요.

purple의 이미지

voljin wrote:
젠투를 소스 컴파일로 쓸 수 있는 것은 소규모 비지니스, 학생, 개인의 홈 정도가 아닐지...

CPU time이 공짜가 아니게 되면 역시 힘들지 않나요?

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

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

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

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

alee의 이미지

송효진 wrote:
alee wrote:
비 전공자/개발자 입장에서 소스 컴파일은 귀찮고 번거로운 일로 느껴집니다. 전산 관련 쪽 공부를 하고 있다거나 관련 직업이 그쪽 계통인 분은 어떨지 모르겠지만, 단지 리눅스를 도구로써 사용하는 사람 입장에서 소스 컴파일은 시간낭비일 뿐입니다.

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

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

젠투자랑 젠투자랑 :D

바이너리 배포본인 데비안 설치하는 것도 귀찮아져서 21세기 들어 딱 한 번 설치한 데비안을 아직도 계속 쓰고 있습니다. 젠투를 어떻게 새로 설치합니까!

정태영의 이미지

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

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

오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...

http://mytears.org ~(~_~)~
나 한줄기 바람처럼..

voljin의 이미지

음. 스레드를 읽으니 srpm과 deb-src 관리 시스템을 ebuild에 준하게 기능을 개선할 수 있다면 좋을 것 같다는 생각이 드는군요.

rpm 진영도 여러가지 개선으로 의존성 지옥을 해결해나가고 있고, 데비안의 바이너리는 말할 필요가 없고, 소스 패치->바이너리화 관리의 유연성만 확보한다면 결정적인 차이점은 해소하는 것이 될테니...

FrogLamb의 이미지

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

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

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

----------------------------------------
Kwonjin Jeong

jj의 이미지

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

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

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

반대로 생각할 수 도 있을듯 합니다.

철저하게 패키징 시스템을 사용했다면, hash값 비교정도로 수정여부를 검사할 수 도 있을테니... ^^

--
Life is short. damn short...

paek의 이미지

GunSmoke wrote:
순선님도 그렇고 요즘은 KLDP에서 troll, flame 전쟁에 대한 제한도 많이 완화된 듯 합니다. 이에 논쟁거리 하나를 던지고자 합니다. (많이 낚이길 기대합니다)

늦은 감이 있지만 제라드 무라니의 security and optimization을 읽고 있습니다. 모든 패키지를 소스 파일을 이용해서 일일이 컴파일 옵션을 최적화해서 설치하는 과정을 소개한 무라니의 노력이 안스럽기 짝이없네요.

개인적으로 더욱 좋아지고 있는 하드웨어 환경에 비추어볼때 이같은 최적화는 비생산적이라고 생각합니다. 소스 파일을 받아와서 컴파일하여 설치하는 방법은 바이너리 설치를 통해서 손쉽게 설치할 수 있는 것에 비해 잃을게 많다고 생각하는데 여러분은 어떻게 생각하십니까?

특정 배포판의 패키지 관리 방식에 대한 논의도 허용하고자 합니다. 본문에서도 알 수 있듯이 저는 젠투 리눅스 회의론자입니다.

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

일예로 튜닝을 통해서 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분+알파 가 되겠지요...

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

--------------------------------------------------------

세상에서 나의 존재는 하나이다.
그러므로 세상에서 나는 특별한 존재이다.
-
책망과 비난은 변화가 아니다.
생각만으로 바뀌는것은 아무것도 없다.

paek의 이미지

jachin wrote:
hey wrote:
소스 기반 패키징 시스템에서 컴파일 옵션이 새로운 것이면 컴파일 해서 중앙 서버에 올려놓고, 이전에 이미 있었던 것이면 자동으로 서버에서 가져다 깔면 어떨까요? :]
소스 코드 컴파일이 비생산적인 방법이라고 할 수 있지만, 생산적인 방법을 통해서 하면 어떨까 생각합니다.

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

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

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

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

gentoo.org 를 보셨는지 모르겠지만, 언젠가의 Gentoo newsletter 에서인가 본걸로 기억하자면 gentoo도 바이너리 버젼을 배포할 계획을 가지고 있고, 윗분이 말하신 그러한 방식(개념?)을 통한 방식이 될것 같다고 본적이 있는것 같습니다.

--------------------------------------------------------

세상에서 나의 존재는 하나이다.
그러므로 세상에서 나는 특별한 존재이다.
-
책망과 비난은 변화가 아니다.
생각만으로 바뀌는것은 아무것도 없다.

욱성군의 이미지

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

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


소스 설치와 바이너리 설치 비교의 대상은
최적화가 아닙니다. 제가 위에 써 놓은 글처럼
'패키지 설치에 있어서의 유연함' 입니다

다른 젠투 사용자들은 모르겠지만 저는 이런 관점으로
소스 설치를 선호하고 있습니다

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

uriel의 이미지

voljin wrote:
음. 스레드를 읽으니 srpm과 deb-src 관리 시스템을 ebuild에 준하게 기능을 개선할 수 있다면 좋을 것 같다는 생각이 드는군요.

apt-build가 있긴 합니다. 단, 젠투처럼 CFLAG를 바꾸는 것은 못하고 컴파일러에 CPU 아키텍쳐나 최적화 옵션 정도를 지정할 수 있는 정도더군요.

wish의 이미지

garderisia wrote:

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

님 주장을 정리하면.

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

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

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

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

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

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

utpark의 이미지

정태영 wrote:
이 쓰레드를 읽다보니 확실히....

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

저에게는 젠투가 이 혹성에서는 제일 좋은 배포본입니다..
(다른 혹성은 가본적이 없어서리..)
앞으로도 그렇게 남도록 열심히들 해야 겠지요.. 8)

정태영의 이미지

garderisia wrote:
advanced wrote:
소스 설치와 바이너리 설치 비교의 대상은
최적화가 아닙니다. 제가 위에 써 놓은 글처럼
'패키지 설치에 있어서의 유연함' 입니다

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

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

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

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

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

Quote:
unfix ~ # emerge -pv mysql

These are the packages that I would merge, in order:

Calculating dependencies ...done!
[ebuild U ] dev-db/mysql-4.1.13-r1 [4.0.25-r2] +berkdb -big-tables -cluster -debug -doc -extraengine -geometry -minimal -perl +readline (-selinux) +ssl -static +tcpd -utf8 16,735 kB

Total size of downloads: 16,735 kB
unfix ~ #

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

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

php 는 한 수 더뜨죠 --;;

Quote:
unfix ~ # emerge -pv mod_php

These are the packages that I would merge, in order:

Calculating dependencies ...done!
[ebuild R ] dev-php/mod_php-5.0.4 -adabas -apache2 -bcmath -berkdb -birdstep -bzip2 +calendar -cdb +cpdflib +crypt -ctype -curl -curlwrappers -db2 -dba -dbase -dbm -dbmaker -dbx -debug -dio -empress -empress-bcs -esoob +exif +fam -fdftk -filepro -firebird -flatfile -frontbase -ftp +gd +gd-external -gdbm -gmp -hardenedphp -hyperwave-api +iconv +imap -informix -ingres -inifile -interbase -iodbc +jpeg -kerberos -ldap -libedit -mcve -memlimit -mhash +mime +ming -mkconfig -mnogosearch -msession -msql -mssql +mysql -mysqli +ncurses -nis +nls -oci8 -odbc -oracle7 -ovrimos -pcntl -pcre -pfpro +png -posix +postgres -qdbm +readline -recode -sapdb -sasl +session -sharedext -sharedmem -simplexml -snmp -soap +sockets -solid +spell -spl +sqlite +ssl -sybase -sybase-ct -sysvipc -threads +tidy +tiff +tokenizer +truetype -wddx +xml2 +xmlrpc -xpm -xsl +zlib 4,620 kB [1]

Total size of downloads: 4,620 kB
Portage overlays:
[1] /usr/local/portage
unfix ~ #

오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...

http://mytears.org ~(~_~)~
나 한줄기 바람처럼..

jongwooh의 이미지

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

수십대 단위로 계정을 판매하는 경우 (호스팅같이) 컴파일 환경을 개별 기계마다 만드는건 그리 좋은 방법이 아닐겁니다.

하지만 빌드서버를 하나 만들어서 자동 설치 스크립트를 잘 짜두면 그것 이상으로 편한 방법이 없습니다.

구글,야후등등이 이런 방법을 쓰는데 꼭 큰 회사만 쓰란 법은 없습니다.

어쨋든 대중적 리눅스 배포본들은 서버 팜 관리할때 그리 좋은 환경을 제공해 주진 않죠.

소스 배포와 컴파일 서치의 간편함은 FreeBSD의 ports 시스템이나 NetBSD의 pkgsrc 가 제일 뛰어나다고 생각합니다. 약간만 고치면 서버팜에도 적용 가능하죠.

pkgsrc는 이제 NetBSD외에도 다른 un*x 에서도 사용 가능하도록 되어 가고 있으니까 한번 고려해 보십시요. http://www.pkgsrc.org

you must know the power of dark side.

voljin의 이미지

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

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

무한포옹의 이미지

paek wrote:

...

일예로 튜닝을 통해서 10대가 할일을 바이너리로 20대라고 했을때 이를 1년간 IDC에 넣어두고 사용한다고 할때, 이경우 IDC비용이 대당 매달 20만원이라고 할때 10대 일경우 200만원, 20대일경우 400만원 입니다.

...

소스 컴파일 해서 100% 성능 향상이 되는 프로그램을 아직 본 적이 없습니다.
가정에서 비약이 심한 만큼 설득력이 많이 줄어든다고 생각하지 않으십니까?

-------------------------------
인생 뭐 있음!

sio4의 이미지

무한포옹 wrote:
paek wrote:

...

일예로 튜닝을 통해서 10대가 할일을 바이너리로 20대라고 했을때 이를 1년간 IDC에 넣어두고 사용한다고 할때, 이경우 IDC비용이 대당 매달 20만원이라고 할때 10대 일경우 200만원, 20대일경우 400만원 입니다.

...

소스 컴파일 해서 100% 성능 향상이 되는 프로그램을 아직 본 적이 없습니다.
가정에서 비약이 심한 만큼 설득력이 많이 줄어든다고 생각하지 않으십니까?

두 배니까 200%죠?

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

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

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

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

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

--
"The love you take is equal to the love you make." The End, by Beatles

dagui의 이미지

기업에게 가장 많은 부담을 주는 비용은 [인력]입니다.
사람 한명을 쓰기 위해서는 월급 뿐만 아니라 교육비용이나 근무를 위한 제경비, 교육비용 등등.. 뿐만 아니라 수치으로 환산하기 거시기한 무형의 부담도 많습니다.

즉 서버 성능 몇%절감 또는 몇대 절감 보다 훨씬 비싼 것이 인력입니다.

대충 설치한 서버 20대의 역할을 최적화된 서버 10대가 감당할수 있다는 가정은 동의하기 힘듭니다만..(현실적으로 그런식의 절감이 가능한 경우는 많지 않을겁니다. 아마 거의 없을 겁니다.)

비슷하게 예를들면 한명이 꼬박 투여되서 최적화된 10대의 서버를 구성하고 유지관리하는것 보다
대충 구성된 서버 20대를 관리하면서 오히려 다른 일(더 많은 서버를 관리)을 할 수 있는 여유가 있는 것이 회사에는 훨씬 이익인 것입니다.

저는 원래 빌드 매니아였습니다. 하나라도 더 컴파일해서 설치하는 것을 좋아했었는데요..

업무로서 시스템 관리를 하는 것이라면 바이너리를 사용하는 것이 훨씬 좋다는 생각을 하게 되었습니다.

그것은 보안 버그 패치라던가 신규 서버 구성이라던가 등등 일상적인 관리 업무 이상의 상황이 닥쳤을 때(동시에 관리하는 모든 서버의 커널을 업그레이드해야한다거나..), 밤 덜새고 더 빨리 마칠 수 있기 때문입니다.

MySQL을 예로들어서 바이너리로 사용할 경우 업그레이드 하는 데 걸리는 시간은 다운받는 시간+압축푸는 시간+재시작하는 시간 입니다. 길어도 15~20분을 넘기지 않을 겁니다.
그러나 컴파일하려면 아무리 숙달되고 컴파일 속도가 빨라도 한시간은 걸릴 것입니다.

서버팜과 전용 빌드 서버에 대한 이야기도 있었는데, 제 생각에 그건 진짜 대형 사이트에서나 쓸수 있는 방법이라고 생각합니다.

대부분의 경우는 각각의 서버들이 역할이 다 제각각이고 각각 다른 목적을 위해 구성(최적화)되어야 합니다. 어떤 서버는 Sun 일수도 있고 Windows일수도 있습니다.

일정정도 규모가 갖춰지지 못한다면 관리자들의 개인적 공부를 도와준다는 측면 말고는 별로 이점이 없다고 생각합니다.

서버의 역할과 응용프로그램 요구사항에 필수적인 커스터마이징, 최적화는 당연히 필요합니다.
같은 MySQL 이라고 해도 전체 사이트를 책임지는 main DB일 경우와 일부 팀원들 업무를 지원하기 위한 내부 서버에 설치된 mysql 은 다른 것입니다.

제가 이야기하고 싶은 것이라면
바이너리가 제공하지 못하는 커스터마이징과 최적화라면 하라, 그러나 바이너리가 제공한다면 괜히 2번일하지 마라 입니다.

그리고 또한가지 꼭 짚고 넘어가고 싶은 점.

스스로 설정을 하고, 운영될 시스템에서(최소한 같은 h/w에서) 컴파일한 것이 최적화된 바이너리란 생각은 위험한 생각입니다.
스스로 설정하고 컴파일한 후 벤치마크 테스트를 해보시나요? 몇가지 구성으로 컴파일하고 성능이나 기능을 테스트 보시나요?

내가 몇시간 들여서 구성한 설정은 바이너리 배포본보다 훨씬 보잘것 없는 것일수도 있습니다.
바이너리 배포본은 비록 범용화 하기 위해서이기도 하지만 만들기 위해 몇일 몇달간의 노하우가 들어가 있을 수 있습니다. 훨씬 더 다양한 상황과 옵션으로 테스트된 것입니다.

Apache+PHP+MySQL을 설치할 때 저는 대부분 MySQL은 바이너리로, Apache+PHP는 컴파일합니다. (Apache+PHP는 추가 모듈 지원을 구성해야 하기 때문에 어쩔수 없기 때문이죠.)

MySQL은 바이너리로 까는 이유는 MySQL 바이너리의 최적화를 믿기 때문이고, 바이너리 배포본보다 더 잘 최적화할 자신이 없기 때문입니다.

내가 직접할수 있는 최적화는 configure --help 해보고서 bdb를 넣을것이냐 뺄것이냐를 결정하는 정도 수준입니다.

하지만 MySQL 바이너리 배포본은 어떤 컴파일러를 써야할지에서 부터 시작해서 각 플랫폼별로 CFLAGS에 어떤 옵션을 줘야할지, 어떤 부분은 어셈블리 코드로 대치해야할지 등 수많은 빌드/테스트 반복해서 만들어 낸 것입니다.

내가 MySQL 배포본 제작자들보다 더 잘할 수 있는 것은 내 서버가 진정으로 필요로 하는 것을 만들 수 있다는 것입니다. "내 서비스"를 위해 필요한 것에 집중해야합니다.

송효진의 이미지

젠투얘기만 나오니까 반감생기는 분도 있으신것 같아서 조심스러워지지만,
mysql ebuild 보면 CFLAGS 등도 자동으로 건드려줍니다.
완전히 따라잡진 못한다 해도 근접하게 흉내는 내줍니다.

젠투 개발진은 가려운 부분을 알아서 잘 긁어주는 재주를 지녔습니다. :lol:

주요 패키지에는 크리티컬한 CFLAGS 등을 빼거나 고치는 설정이 포함되어져 있습니다.

그리고,
mysql 개발진은 CFLAGS 에 도가 터서 그렇다고 해도,
대부분의 다른 소프트 개발진은 그냥 이정도로 하면 이상 없다 정도의 권고만 하는 정도니 mysql 바이너리는 예외로 두고 싶네요. :wink: