폐쇄적으로 변해가는 리눅스

저도 Xeon의 하이퍼쓰레딩 기능과 IRQ balance 문제 때문에 시스템이 자꾸죽는 문제가 발생했었습니다.

하이퍼쓰레드 문제때문에 바이오스도 업데이트도 해주어야 했고, IRQ 문제는 레드햇에 근무하는 것으로 생각되는 Ingo molnar 인지 mingo 아이디 쓰는 사람의 irqbalance 패치를 받아서 컴파일 했었습니다.
(http://www.hardrock.org에서 구했습니다.)

패치를 받아서 설치하고 난 후에는 IRQ가 한쪽 CPU로 쏠리지 않고 잘 배분 되었지만, X를 띄우고 Mozilla를 실행하면 전체 시스템이 죽어버리더군요.

생각끝에 데비안 커널 소스를 받아다가 IRQ balance 패치를 해주니 Mozilla를 실행해도 시스템이 죽지 않았습니다. 2.4.20과 2.4.22 버전을 데비안 커널소스를 사용하여 패치한 경우에는 시스템이 멀쩡히 돌아갔지만, kernel.org에서 받은 Stock 커널을 사용하여 패치한 경우에는 콘솔상에서는 문제가 없었지만, Mozilla 실행시 시스템이 죽었습니다.

AC 커널을 사용했을 때도 콘솔상의 IRQ 발란스가 잘 되었지만 Mozilla 실행시 죽는 것은 여전했고요... 음...

암튼 Stock 커널과 비교했을 때 데비안 커널에도 많은부분이 패치가 되어 있더군요. 시간이 나면 어떤 부분이 시스템 죽이는 원인인지 분석이라도 시도해 보아야 겠다는 생각을 가지고 있습니다. 원인을 아시는 분은 좀 알려 주세요~

참고로 제 메인보드는 SE7500CW2 입니다.

패치가 되어 있으면 바이너리 RPM도 있겠지만 소스 RPM도 찾아보면 있을 것이고, 당연히 그 안에는 각종 패치들이 들어있습니다. 제대로 찾아보고 위의 얘길 썼는지 상당히 의심스럽군요.

이러한 걱정은 서비스를 제공하는 또다른 회사에서나 할만한 걱정입니다. 최신 하드웨에서 제대로된 기능을 지원하게 하는것은 나름의 각고의 노력이나 노하우가 있어야 되겠죠.

그리고, 그것이 검증되어서 리눅스 커널에 반영되는 것이 늦어질 지는 모르겠습니다만, 제대로 된 패치라면 반드시 반영될 것이고, 그러한 비공개(?) 패치가 필요 없어지겠죠.

그러한 레드헷 수세 등등의 상용 배포판 회사의 정책이 마음에 들지 않으면
데비안이나 젠투를 쓰면 될것입니다. 레드햇만이 리눅스 배포판을 만드는 회사가 아니죠.

소스를 공개안하면, 사람들이 가만있을까요? GPL은 껌인지...?
영세한 Linksys일을 생각하면, 공룡같은 수세나 레드햇이 소스공개를 안할 수 있을런지...

그게 무엇이냐면, 별거 아니지만은...

http://slashdot.org/search.pl?query=linksys&op=stories&author=&tid=117&section=&sort=1

하드웨어 업체도 저렇게 딴지걸고 넘어지는데, 하물며 리눅스로 돈버는 회사는...?

제 생각에도 조금 성급한 의견이 아닌가 싶습니다.

우선, 리눅스 커널의 라이센스는 빼도박도 못하는 GPL입니다. 리눅스 커널에 추가한 내용을 재배포하기 위해서는 그 소스가 반드시 공개되어야 합니다. 위의 글을 읽어보아도 소스코드가 공개되어야 한다는 GPL의 취지를 역행하는 상황은 하나도 보이지 않습니다. 게다가, 일반 서버가 아닌 high end쪽 서버는 예전부터 리눅스 셋업이 쉽지 않았습니다... 재주껏 원인을 짚어내고 패치를 찾아야 합니다. 패치가 없는 경우는 스스로 개발하든지... 혹은 패치가 나올때 까지 기다려야 합니다. 제 경우에도, 석사시절 SMP관련 리눅스 커널 버그 때문에 리눅스 클러스터의 속도가 현저히 떨어졌던 경우를 당한 적이 있습니다. 뉴스그룹에서 다행히 패치를 찾았지만 이 패치가 리눅스 커널 트리에 포함되기까지는 몇개월의 시간이 더 걸렸던 기억이 납니다. 이 역시 일반적인 서버 운영에는 아무런 필요가 없는 패치였습니다.

패치를 공개하는 것과 패치 설치 서비스, 좀 더 나아가 패치 뒤에 있는 기술은 엄연히 다릅니다. 게다가, 프로그래머의 입장에서는 패치를 "공개해야하는" 의무는 있지만 이 패치를 리눅스 커널이나 주요 배포본에 통합시킬 의무까지는 없습니다. 더더군다나, high end쪽 서버는 상대적으로 패치를 만들어 내는 사람은 소수이지만 사용자 입장에서는 시스템 결함이 심각한 손해를 야기하기 때문에 더욱 마음이 급해지기 마련입니다. 따라서, 리눅스가 엔터프라이즈 급으로 발전하면 할수록 이런 추세는 심화될 가능성이 높습니다. 그러나, 이것 자체는 문제삼을 필요는 없다고 봅니다. 중요한 패치는 그만큼 빨리 퍼져나가기 마련입니다. 다만, 중요하지만 사용자가 몇 되지 않는 패치는 퍼져나가는 속도가 상대적으로 느릴 수 밖에 없습니다.

상용 기업의 참여가 두드러지면서 하나 우려되는 점은 그동안 공개된 메일링 리스트에서 언급되던 기술적인 지식들이 예를들어 공개되지 않는 IBM내부의 개발자 메일링 리스트와 같은 쪽으로 옮겨가는 점을 생각해 볼 수 있지만 이것 또한 어쩔 수 없는 일이라고 봅니다. IBM 직원이 아닌 사람들은 공개된 소스 코드를 보는 수 밖에 없습니다. 실제, 소스 코드는 대부분의 기업에서 영업 비밀로 간주하는 관행을 생각해본다면 소스 코드 공개 이상을 리눅스 관련 기업들에게 요구하는 것은 무리가 있지 않을까요? 그리고, 소스 코드 공개를 통해 좀 더 나은 derivative work를 구할 수 있는 가능성을 생각해 본다면 이들 상용 회사에서도 어느 정도 수준까지는 소스코드를 자발적으로 공개할 유인이 충분하다고 봅니다. 소스 코드의 공개 유인이 충분하고, 소스 코드 비공개에 대한 페널티가 확실한 상황에서 이런 걱정은 지나친 기우가 아닐까요.

아직은 성급한 의견같은데요.

새로운 기능은 항상 개발 버전에 배포되고 그게 안정화되고 테스트 된 후에 정식 릴리스에 포함되겠죠.. 아마 개발되고 상당한 테스트를 거친 후에 말이죠..

IBM에서 개발중인게 아직은 2.6에서 개발되고있고.. 2.6은 정식 발표되지 않고 테스트중(정확하게는 모름.. 리눅스계를 떠난지 오래서..)인것으로 알고있는데, 안정화되고 2.6이 정식 발표되면 포함되겠죠.. 기다리시는게..

정 급하다면 위험을 무릅쓰고 2.6 테스트 버전을 쓰면되죠.. 책임은 사용자게에.. ^^

오픈소스가 필요하면 가져다쓰고, 거기서 부족하면 다른 사람이 수정한거 있으면 가져다 쓰고, 없으면 직접 고친다, 그리고 오픈한다 그런거로 개념잡고있는데..

2.6에 있는 코드가 2.4에 없으면 ..(안해줬겠죠. 뭔가 이유가 있겠자만) 직접 2.4에 merge 해보는것도 좋은 방버일듯한데..

왠지 투정부리는것 같군요.

리눅스 유저들이 항상 감시해야겠죠.

공개하거나 말거나는

기업 맘대로라뇨?

그건 GPL 을 모르거나 알면서도

개무시 하는 태도에서 나오는것 아닙니까?

리눅스 커널 소스는 패치까지 반드시 공개되야 합니다.
:o
-------------------
태초에 말씀이 있었으니....

레드햇등의 커널 패치가 kernel.org에서 배포하는 바닐라 커널에 적용되기 까지는 시간이 좀 걸리더군요.

예를 들어... 인텔사의 기가빗 랜카드 모듈 e1000같은 경우도 레드햇 커널에는 비교적 최근 버젼의 모듈이 포함되어 있습니다.

어차피 레드햇 어드밴스드 서버도 SRPM 즉 소스는 공개되어 있으며 GPL 위반이 아닙니다. 그리고 그러한 패치들이 시간 간격이 늦기는 하지만 바닐라 커널에 적용됩니다.
아무래도 상용리눅스 회사다보니 최신 하드웨어나 기능에 대한 요구사항이 많을 테고 민감하게 움직입니다.

소스공개해주고 원하면 패치해서 써라. 혹은 가져다 써라라고 하는 회사에게
우리가 더 편하게 쓰도록 패키징도 해주고 공짜 문서도 주고 패치 제공도 해주고 질문에 답도 해달라라고 요구할 수는 없겠지요.
소스는 공개, 서비스나 지원은 유료... 전혀 문제 될 것이 없어 보입니다. :P

커널이 복잡해지면서 여러가지 다양한 요구조건들이 늘어나고 현실적으로 모든 요구조건들을 바닐라 커널에서 만족시켜 주기가 불가능하기 때문에 이미 비공식 커널 소스트리들이 매우 많이 생겨 있고, 또 계속해서 생기고 있는 상황입니다. 최근의 lwn.net의 커널 섹션에 보면 현재 존재하고 있는 다양한 비공식 소스트리들에 대해 소개하고 있는데 한번쯤 살펴볼 만 합니다.

아직까지는 커뮤니티의 테두리 안에서 상용 리눅스 업체(레드햇,수세등...), 상용 유닉스 업체(IBM, HP등...)들이 모두 함께 개발 작업을 진행해 나가고 있지만 언제 상황이 바뀔지는 아무도 모릅니다. 그만큼 리눅스 커널이 많은 발전을 해 나가고 있는 것이라고 볼 수도 있지만 부수적으로 관리의 문제가 불거져 나오고 있는 것이지요.

리눅스 커널에 대해 상당한 수준의 전문성을 갖춘 업체라면 이제는 굳이 mainline 커널 개발 작업에 매달리기보다는 자신들의 소스 트리를 별도로 구축하고 그것을 위주로 작업하고 mainline 커널과 점점 멀어질 수도 있고, 소극적으로 패치를 제공하는 등의 여러가지 전략적인 액션을 취할 수 있는 여지도 충분히 있습니다.

아직까지는 여러 업체들이 룰을 잘 지켜서 작업을 하고 있는 것처럼 보입니다만 시장 상황이 급격히 변화되거나 경쟁이 심화되면 회사의 생존을 위해서 그 회사에 소속되어 있는 커널 개발자들의 개인 의지와 상관없이 좀더 닫힌(?) 자세로 커널 개발에 참여할 가능성이 없다고는 이야기하기 힘들겠죠.

소스코드가 GPL로 공개되어 있고, GPL이 파생 저작에 대한 소스코드 공개를 명시하고는 있지만 이 룰을 잘 지키면서도 그 파생 저작물을 실사용자가 이용할 때 어느정도의 전문적인 지식이 없이는 이용 자체가 쉽지 않아서 이에 대한 컨설팅 서비스 등이 필요하게 되는 경우가 이미 발생하고 있고 아마 점점 더 많이 생길 것이라 봅니다. 여기서 비즈니스 기회가 창출되겠죠.

그렇게 되는 것이 폐쇄적이라고 이야기하기는 어폐가 있겠습니다만 mainline 커널 소스가 거의 절대적인 신임을 얻고 비공식 커널 트리가 거의 (필요) 없었던 수년전의 상황과 비교해 보자면 분명 추가 비용이 발생할 가능성이 커지고 있는 것이니 시간이나 비용을 아끼고자 하는 사람(기업)의 입장에선 달가운 일이 아니겠죠.

제가 만약 배포판을 제작해서 판매하는 회사라면 기업용 배포판을 납품하고 기술지원을 맺으면서 우리 회사에서 제공하지 않은 패키지에서 발생하는 문제는 책임을 지지 않겠다고 하고, 특히 커널에 어떤 기능이 필요해서 최근에 새로 나온 패치를 적용해야 할 때도 꼭 우리 회사에서 만들어서 테스트하고 고객사에 제공한 커널 패키지를 사용했을 때만 기술지원을 해 주겠다고 하겠습니다. 고객 입장에선 커널을 포함한 수많은 소프트웨어들의 업데이트를 일일이 쫓아간다는 것이 현실적으로 불가능하거나 비용이 많이 들기 때문에 고객사에서 배포판을 별도로 만들고 계속해서 스스로 관리하지 않는 한은 배포판 업체와 유지보수 계약을 함께 맺을 수밖에 없고, 그런 상황에서 위와 같은 기술지원 조건을 내세웠을 때 거부할 이유도/방법도 별로 없습니다. 그렇게 되면 이제 더이상 고객사에서는 구입한 리눅스 배포판에 없는 기능이 커널 메일링 리스트에 떠서 그것을 이용하고 싶어도 기술지원이 문제가 되기 때문에 그 시스템에 대한 기술지원을 포기하지 않고는 그 패치를 이용하기가 어렵게 됩니다.

레드햇이 예전에 레드햇 네트워크를 구축하고 등록 고객에게만 업데이트된 패키지를 곧바로 설치할 수 있는 통로를 제공하고, 어드밴스드 서버 제품의 릴리즈 주기를 길게 하면서 역시 등록 고객에게만 곧바로 설치 가능한 바이너리 rpm을 제공하고, 등록하지 않은 고객에게는 별도로 컴파일이 필요한 소스 rpm만을 제공하는 것도 다 위와 같은 맥락에서 이루어지고 있는 것이라고 봅니다.

그럼 데비안 같은 공개 배포판을 쓰면 되지 않냐라고 하시는 분도 계실 수 있는데, 개인 사용자의 경우는 문제가 되지 않습니다만 기업에서 리눅스를 도입할 때는 위와 같은 부분들이 고려되어야 하기에, 리눅스 커널이 하나의 소스트리에서 집중적으로 개발되면서 개발 활동들과 그에 파생되는 패치들이 그 트리에 100% 적용되기 어려워지는 지금의 상황은 분명 상용 배포판 업체에는 매우 좋은 기회입니다. 따라서 개발 능력 뿐만 아니라 개발 작업을 관리하는 능력도 갈수록 중요해 지겠죠.