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

madman의 이미지

한양대 리눅스 유저그룹에 누가 올린 글입니다. 읽어보니 무척 공감이 가는군여.

=====
리눅스는 변하고 있다...

앞으론 www.kernel.org 에서 배포하는 표준 커널은 맛보기 커널이 될 가능성이 높다.

최근에 황당한일을 많이 겪는다...

버그 및 기능들이 제대로 된 패치 커널을 구할려면 아무래도 직접 일일히 패치 정보를 구해서 패치를 하거나 아니면 돈을 주고 커널을 사야 되는 일이 조만간 발생할것 같다.

www.kernel.org 커널은... 뼈대만 제공할뿐 실제로 제대로 쓸려고 하면 쓰지 못할것이다.

우리는 www.kernel.org 커널을 가지고 쓰다가... 최근에 매우 어려운 일을 겪고 있다.

1. 제온의 하이퍼 쓰레딩 문제
2. 리눅스 커널 레이드의 버그 문제
3. 제온 SMP 에서 인터럽트 문제
4. 스왑데몬의 문제
5. 인텔 랜카드의 문제
6. EXT3 LOCK 문제

물론 위에서 나열한 문제들에 대한 표준 커널에선 기능상 문제는 전혀 없다. 일반적인 사용자들은 모두 잘 동작한다.

우리는 리눅스에 매우 혹독한 작업을 시킨다.
그렇게되면 위에 나열한 몇가지 문제로 인해서 서비스를 중단하는 사태나 성능을 제대로 못끌어올리는 사태가 온다...

물론 위와 같은 문제는 뉴스그룹이나 커널 메일링 리스트를 통해 알아낸 자료를 바탕으로 www.kernel.org 에 패치를 가해서 잘쓰고 있었다.

그렇지만 요즘엔 수세 엔터프라이즈 커널을 쓰거나 래드햇 엔터프라이즈 커널을 쓴다. 이것들은 위와 같은 문제를 미리 해결해놓았다. 아직까진 공개로 구할수 있지만 래드햇은 래드햇 어드밴스 서버 3.0 부턴 웬지 모르게 공개하지 않을것 같다...

그러나 요즘엔 저러한 문제를 발견시에 오픈소스 사이트나 기타 메일링 사이트에서 패치 소스를 쉽게 구하지 못한다...

그이유는 나도 모른다.... 한가지 예측이 되는것은... 최근에 오픈소스나, 커널 개발자들이 IBM, 수세, 래드햇, 구글사 등의 회사에 높은 연봉으로 일하고 있는것으로 알고 있다.

오늘도 제온CPU SMP 일때 인터럽트가 여러 CPU에 골고루 발란싱 안되는 문제를 가지고 씨름하다가... 뉴스그룹에서 찾은 해답은
결국 래드햇 2.4.18-27.X 에 패치가 되었으니 그 커널을 쓰라는 답이였다.

답을 준사람은 커널 개발자 같은데... 래드햇사에 근무하는 사람같다... 따로 패치 소스를 제공하지 않는것에 대해선 약간 실망 스러웠다...

2.4.18-27.X 커널을 구해서 테스트 결과 위에 문제는 말끔히 해결이 되었다.

앞으로는 어떻게 될것인가?

2.6 커널엔 IBM등 상용 기업 엔지니어들이 코어 개발에 거의 주도를 하였다.

상용기업들의 커널 엔지니어들은 2.4 커널엔 엔터프라이즈급의 우수한 기능을 넣지 않았다. 2.6 커널에만 넣었다. 무엇을 의미하고 있을까?

래드햇에선 앞으론 커널 소스를 제공하지 않고 커널 바이너리하고 모듈만 제공하는 전략을 쓰겠다고 한다... 그리고 자기네가 공개한 커널소스를 가지고 사용자가 직접 컴파일한 것에 대해 문제가 생길시엔 책임을 지지 않겠다고 한다.
분명 오픈한 커널과 바이너리 커널과는 소스가 틀릴 가능성이 높다. MS사 처럼 되어가는것은 아닌지?

우리는 문제를 해결하다가 못해서 답답해서 결국 래드햇등을 통해서 커널을 구입해야 될지도 모르겠다...

불과 1년전 2.4.17 이하 커널만 해도 안그랬는데... 요즘 상용 리눅스 기업들의 움직임은 이상한점을 많이 느낀다...

상용기업들의 우수한 지원을 받아서 상용 리눅스가 등장하는것은 찬성인데...상용기업들의 노하우를 직접 모두 공개하지 않는것은 좀 문제가 있다...
====

기업도 먹구 살아야 하니깐 이런식으로 커스터마이즈해서 돈버는건 당연한 거겠죠. 그치만....웬지 리눅스가 점점 더 폐쇄적으로 변해갈 것이라는 생각이 드네요.

Necromancer의 이미지

커널보다 훨씬 더합니다.

직접 컴파일하면 심심하면 에러 뜨는 놈입니다.

배포본 개발자들이 그거 어떻게 만들어내는지 궁금하네요.

Written By the Black Knight of Destruction

이광우의 이미지

저도 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 입니다.

Be Creative For Fun!!

ganadist의 이미지

Quote:

그렇지만 요즘엔 수세 엔터프라이즈 커널을 쓰거나 래드햇 엔터프라이즈 커널을 쓴다. 이것들은 위와 같은 문제를 미리 해결해놓았다. 아직까진 공개로 구할수 있지만 래드햇은 래드햇 어드밴스 서버 3.0 부턴 웬지 모르게 공개하지 않을것 같다...

제가 알기로 Redhat AS부터는 바이너리는 판매하고 SRPMS는 공개하는 정책인걸로 알고 있습니다.

Quote:

그이유는 나도 모른다.... 한가지 예측이 되는것은... 최근에 오픈소스나, 커널 개발자들이 IBM, 수세, 래드햇, 구글사 등의 회사에 높은 연봉으로 일하고 있는것으로 알고 있다.

일한만큼 버는 것이겠죠 :)

Quote:

오늘도 제온CPU SMP 일때 인터럽트가 여러 CPU에 골고루 발란싱 안되는 문제를 가지고 씨름하다가... 뉴스그룹에서 찾은 해답은
결국 래드햇 2.4.18-27.X 에 패치가 되었으니 그 커널을 쓰라는 답이였다.

답을 준사람은 커널 개발자 같은데... 래드햇사에 근무하는 사람같다... 따로 패치 소스를 제공하지 않는것에 대해선 약간 실망 스러웠다...

레드햇 커널 패치야 구하기 쉬워서 따로 설명을 안붙인게 아닐까요?

Quote:

2.6 커널엔 IBM등 상용 기업 엔지니어들이 코어 개발에 거의 주도를 하였다.

상용기업들의 커널 엔지니어들은 2.4 커널엔 엔터프라이즈급의 우수한 기능을 넣지 않았다. 2.6 커널에만 넣었다. 무엇을 의미하고 있을까?

krixxx wrote:

왜 윈도우즈 3.1은 기본으로 tcpip를 지원하지 않은건가.. 왜 95에만 기본으로 들어간건가.
와 같은 질문이 아닐까요?

Quote:

상용기업들의 우수한 지원을 받아서 상용 리눅스가 등장하는것은 찬성인데...상용기업들의 노하우를 직접 모두 공개하지 않는것은 좀 문제가 있다...

공개하고 말고는 기업들 마음이 아닐까요? 굳이 배내놔라 감내놔라 하기까지는 필요없다고 봅니다.

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

wkpark의 이미지

Quote:

오늘도 제온CPU SMP 일때 인터럽트가 여러 CPU에 골고루 발란싱 안되는 문제를 가지고 씨름하다가... 뉴스그룹에서 찾은 해답은
결국 래드햇 2.4.18-27.X 에 패치가 되었으니 그 커널을 쓰라는 답이였다.

답을 준사람은 커널 개발자 같은데... 래드햇사에 근무하는 사람같다... 따로 패치 소스를 제공하지 않는것에 대해선 약간 실망 스러웠다...

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

Quote:

그러나 요즘엔 저러한 문제를 발견시에 오픈소스 사이트나 기타 메일링 사이트에서 패치 소스를 쉽게 구하지 못한다...

그렇지만 요즘엔 수세 엔터프라이즈 커널을 쓰거나 래드햇 엔터프라이즈 커널을 쓴다. 이것들은 위와 같은 문제를 미리 해결해놓았다. 아직까진 공개로 구할수 있지만 래드햇은 래드햇 어드밴스 서버 3.0 부턴 웬지 모르게 공개하지 않을것 같다...


이 이하, 이분은 추측을 거의 기정사실화 하다 시피하며 글을 쓰셨군요.

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

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

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

온갖 참된 삶은 만남이다 --Martin Buber

kookooo의 이미지

이런 글쓰다 보니 이미 박원규 님이 쓰셨군요

RPM을 찾아보라는 건 많은 의미를 담고 있고요..
물론 Redhat Network 이 유료화 되었지만.. SRPM을 구하면 패치는 구한것이 되겠죠..

저도 여기서 글쓰다 보니 왠만한 것들은 말을 짧게 하게 되더군요..

늘 성의있는 대답을 기대하는 것 그 기대치가 큰것이 문제였던거 같네요..

jj의 이미지

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

--
Life is short. damn short...

zienie의 이미지

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

링크시스 껀???이 무엇인지
알려주시면 감사하겠습니다. :D

##########################################################
넘어지는건 아직 괜찮다.
하지만 넘어질때마다 무언가를 주워서 일어나자.

jj의 이미지

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

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

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

--
Life is short. damn short...

vacancy의 이미지

라이센스가 GPL인 이상,
소스 공개를 안할수는 없을 것 같은데요.
너무 추측성의 글이 아닌가 싶습니다.

kernel.org쪽이 배포판들의 커널들보다
패치 적용이 늦는건 사실입니다만,
그건 사실 어쩔수 없는 일 같은데요.
패치 하나 할때마다 릴리즈할수도 없고요.
그렇다고 패치가 적용되지 않는 건 아니라고 봅니다.

윗 글처럼 기업의 kernel source가 싫으시면
데비안이나 젠투의 source를 받으시는게 좋을것 같네요.
그래도 이모저모 패치가 적용되어있으니까요.

logout의 이미지

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

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

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

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

"I conduct to live,
I live to compose."
--- Gustav Mahler

Prentice의 이미지

한양대 리눅스 유저그룹에 누군가가 wrote:
앞으로는 어떻게 될것인가?

2.6 커널엔 IBM등 상용 기업 엔지니어들이 코어 개발에 거의 주도를 하였다.

상용기업들의 커널 엔지니어들은 2.4 커널엔 엔터프라이즈급의 우수한 기능을 넣지 않았다. 2.6 커널에만 넣었다. 무엇을 의미하고 있을까?

단순히 2.6 커널이 현재 개발 커널이니까 2.6에 넣었다는 것 아닐까요? ^^;

whitekid의 이미지

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

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

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

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

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

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

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

What do you want to eat?

enmir의 이미지

그런데 래드햇이나 수세등 배포판으로 이름을 얻은 회사들의
공개버전과 상용버전과의 의도적 차이에 대한 의구심은 지금에서
충분히 의미가 있다는 생각이 드는군요

GPL하의 또는 오프소스하에 배포판은 소프트웨어의 판매수익보다는
기술적 지원을 통한 이윤획득이 일반적인 수익모델이 될터인데
혹여나 배포판 판매를 통한 수익에 맛을 들이고 이를 강화하는 전략으로
가거나 한다면 분명 패쇄적 분위기로 흐를 여지가 있다고 봅니다.

비지니스모델로 오픈소스는 그 태생적 한계로 거대 규모의 이윤창출을
기대한다는 것은 GPL과의 거리두기를 통해서만이 가능하다는
생각입니다.

태초에 행동있었으니....

penguinpow의 이미지

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

공개하거나 말거나는

기업 맘대로라뇨?

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

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

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

fibonacci의 이미지

하이퍼 쓰레딩 SMP에 대한 패치를 레드햇 커널 개발자가 만들어, 바이너리를 그들의 상용배포본에 포함시키고 있지만, 소스는 공개되어 있다고 알고 있습니다. 그 소스를 레드햇이 아닌 다른 리눅스에서 잘 컴파일되도록 다듬어서 잘 작동되도록 쓰는건 사용자 몫입니다. 레드햇에서 그것까지 해 줄 의무는 없습니다. 아마도 글쓴이는 그런것때문에 투덜거린것 같으나, 오픈소스란것이 사용자의 자발적인 개발에 대한 참여로 이루어지는 것이란 걸 감안하면 앞의 분의 말씀처럼 너무 투정이 아닌가 싶습니다.

공룡 기업들이 리눅스진영에 참여함으로써 리눅스의 성능은 더욱 강력해 지고 있습니다. 해커들이 그냥 심심해서 만들기 어려운 수준의 하이엔드기능들이 리눅스 커널에 추가되고 있습니다. SMP도 이런 산물중 하나입니다.

No Pain, No Gain.

mania12의 이미지

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

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

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

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

cjh의 이미지

어차피 소스는 공개되어 있으니 그거 갖고 왈가왈부할 것은 아니지만,

상업적 지원을 바탕으로 특정 회사의 커널에 계속 패치가 추가되고 정식 버전의 반영이 늦어지면 늦어질수록 사람들은 점점 더 정식 버전 대신 그 회사 가서 커널을 받을려고 할 겁니다. 기능 추가나 버그가 더 많이 잡혀 있으니까요. 그냥 래드햇 커널 갖고 자기한테 맞게 고쳐 쓰지 불편하게 kernel.org 커널 받아서 내게 필요한 패치를 어디서 받아야 하나 이것저것 고민하지 않게 된다는 것이죠.

그런 상황이 계속되면 업체용 버전과 정식 버전의 갭이 많이 생겨서 나중에는 업체가 실질적인 주도권을 쥘 수도 있습니다. 의도하지 않았든 의도하였든 간에 말이죠.

그런 일이 생기지 않으려면 결국은 정식 커널 관리자들이 부지런히 일하는 수 밖에 없을 것 같네요. 중간중간 릴리즈를 더 짧은 주기로 한다거나... 옛날에는 하루에 패치레벨 두개씩 올라간다고도 했었는데 요즘에는 예전보다 많이 느린 것은 분명해 보입니다...

--
익스펙토 페트로눔

권순선의 이미지

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

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

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

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

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

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

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

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

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

maddie의 이미지

젠투 리눅스의 경우 바닐라 커널부터 레드햇커널 등 여러 커널의 소스트리를 제공하더군요. 즉... 소스가 공개되지 않는다는 건 맞지 않는 것같구요..

바닐라가 하이엔드급의 희안한(?) 하드웨어 구성에 안맞을 수 있지만, 어차피 바닐라를 개발하는 개발자들의 PC가 대부분 희안한 머신이 아닌 이상, 그리고 버그 리포팅이 많지 않다면 당연히 생기는 문제라고 생각합니다.

제가 사용하는 리브레토에서 2.4커널의 리눅스로 거의 모든 하드웨어를 사용하기 위해서는 패치가 대략 3번정도 들어갑니다. 그 이유를 따져보니(패치를 살펴보니) 일부 하드웨어가 일반적인 irq를 요구하지 않기 때문에 일어나는 문제더군요. 사운드의 경우 진짜 소스코드에서 irq부분만 수정합니다.

그런 부분까지 커널 개발자들이 해결해야 한다는 건 좀 그렇지 않습니까? 윈도야 하드웨어 밴더들이 드라이버를 제공하지만 리눅스의 경우 그런것도 아니잖습니까...

그래서 느끼는 건데 리눅스의 경우 커널의 버전이 올라갈때마다 그 버전에 맞는 패치를 구해야 한다는 게 보통일이 아니더군요. 특히 재가 사용하는 리브레토의 경우는 원래 5개의 패치를 사용했었는데, 두개가 커널버전이 맞지않아 다시 구하는 해프닝이 있었습니다.(일본어도 모르는데 일어 사이트 뒤지는 거 너무 힘들어요 ㅜ.ㅜ) 프비는 커널이 거의 변하지 않는지 4.2에서 적용된 패치가 4.8까지 적용이 되더군요.(프비는 근데 아예 못지원하는 하드웨어가 좀 있어서 ㅡ.ㅡ)

머 어차피 리눅스나 기타 마이너 오에스를 이용하는 부분에 싸게 사용할 수 있는 만큼의 반대급부로 생각하고 그걸 즐겨보는 것도 나쁘지 않을 것같습니다. 그리고 그런 경험을 공유하여 여러사람의 에너지를 덜 소비하게 하는 것도 좋구요.(사실 요즘 리눅스 사이트에서 고급 정보는 보기 힘들더군요...그냥 사견입니다.)

힘없는자의 슬픔

Tony의 이미지

리눅스 커널의 주도권이 IBM이든 RedHat이든 어디로 넘어가도 그건 나쁜일이
아니라고 생각합니다. GPL아래에 있다면 말이지요...
리누스씨나 osdl팀 또는 kernel.org쪽 사람들이 리눅스의 영원한 관리자가
되라는 법은 없다고 생각합니다. 더 잘 할 수 있는 사람이 잘 하면 사람들은
거기로 갈꺼고 그보다 더 잘하는 사람이 생기면 다시 또 옮겨가기 마련이겠죠...

리눅스 커널은 리눅스 커널일뿐입니다. 만일 32WAY 제온서버로 고성능
안정 리눅스 시스템을 원하는 사람이 있다면 그 안정성과 성능에대해 보장을
할 사람이 필요로 할것입니다. (그만한 비용을 지불하겠다는 의미였을테니까..)
그 보장할 사람이 IBM이든 RedHat이든이 되면 된다고 생각합니다.
kernel.org 에서 그에대한 보장을 해야한다고 강요할수는 없습니다.
아마도.... kernel.org입장에서는 그런 시스템을 가지신분께서 직접 리눅스를
포팅해서 사용해보고 문제가 발견된다면 패치를 릴리즈하길 원할껍니다.
그게 오픈소스의 생존방식이라는걸 당연히 아시리라 믿습니다.

아무튼 GPL이 여러 염려사항에서 당신을 해방시키리라 믿습니다.

ps. 오히려 그런 GPL의 엄격함이 회사들의 리눅스 채용을 꺼리게 하여
리눅스를 사용하는 사람이 줄어들고 아무도 메인테인 안하게 되어 리눅스가
몰락하게 되는걸 걱정하던 부류의 걱정이 오히려 더 현실성 있게들립니다.
몇년전 이런 주장은 커널 2.6의 등장을 임박해두고 헛 걱정이었다는게
증명되는중이죠? ^^*