데비안이 glibc에서 eglibc로 전환?
데비안이 glibc 대신 eglibc로 전환하게 될 것이라는 흥미로운 소식이 떴네요.
관련 포스팅: http://lwn.net/Articles/332000/ http://blog.aurel32.net/?p=47
eglibc 홈페이지: http://www.eglibc.org
c 라이브러리는 워낙에 의존성이 많이 걸려 있고 리눅스에서 돌아가는 거의 대부분의 프로그램들과 직/간접적으로 얽혀 있는데 glibc는 너무 사이즈가 크고 특히 임베디드 환경에서는 잘 맞지 않는 부분들이 있어서 uclibc 등 임베디드용 c 라이브러리 프로젝트가 그동안 다양한 경로를 통해 시도되었는데 eglibc라는 것이 있다는 건 오늘 처음 알았네요. 최소한 임베디드 쪽에 종사하시는 분들이라면 한번쯤 살펴보시면 괜찮을 것 같습니다.
eglibc의 가장 큰 특징으로 꼽는 것이 사용자 친화적이다라는 것인데 glibc의 현 메인테이너인 Ulrich Drepper의 여러 친화적이지 않은(?) 반응들을 위의 블로그 포스팅에서는 여러가지 사례로 보여주고 있습니다.
- http://sourceware.org/bugzilla/show_bug.cgi?id=4980
- http://sourceware.org/bugzilla/show_bug.cgi?id=5070
Ulrich Drepper가 원래 그런 사람인지는 잘 모르겠는데 '니가 나한테 월급을 주는 것도 아니면서 더이상 이래라저래라 하지 마라' 뭐 이런 식의 이야기까지 하는 걸 보면...최소한 저기에서만 봤을 땐 상당히 살벌하네요. (하지만 이분은 실질적으로 glibc를 포함한 다양한 오픈소스 프로그램에 매우 오랜 기간동안 기여해 온 사람입니다. 성격은 어떤지 모르지만...)
그냥 위의 블로그 포스팅과 거기 얽힌 관련 URL만 보고 저도 단편적으로 적은 것인데 혹시 좀더 자세한 사정을 아시는 분 계신가요? eglibc를 혹시 써보신 분이 계시면 경험담을 알려 주셔도 좋은 정보가 될 것 같고요.
댓글
음....
임베디드 경험 같은건 없지만.. uClibc 처럼 임베디드용으로도 쓸수 있으면서도..
기존 glibc 와 소스, 바이너리 호환성을 가진것이 장점같아 보이는데요..
실력은 좋은데 같이 함께하기 힘든 사람들이 있지요.
저도 한 성격 한다고 생각하는 편인데 이런 제가 보기에도 실력만 쌓고 인격을 쌓는 건
평생동안 생각 해본 일도 없는 사람마냥 행동하시는 분들이 드물게 계시지요. (많지는 않아요.)
요즘은 아주 형편없는 수준이 아니라면 인간이 된 사람이랑 같이 하고 싶습니다.
실력이 부족하면 그에 맞는 일을 찾아서 하면 되지만, 인간이 안 된 경우는 해결 방법이
없거든요.
PS> 어느 사람이 꽤 실력있는 것 같아 살짝 존경(?)하고 있었는데 그 사람 글을 보고
'실력과 인격이 트레이드 오프 관계에 놓인 사람이군.'이구나 생각했습니다.
--
B/o/o/k/w/o/r/m/
--
Minimalist Programmer
음 뜨끔하군요. --;
음 뜨끔하군요. --;
초보자를 위한 하우투를 내놓고선 그런말을 너무 많이 들어서 T.T
어떤 분 블로그에 있던 말처럼 난 사람이 된 사람이라는 것을 보장하지 않겠죠.
난 사람과 된 사람은 판단 기준이 제 각각이나, 보통 사람들은 (난 사람 == 된 사람)이라고 막연히 기대했다가 실망을 느끼는 경우가 많죠.
glibc 같은 시스템
glibc 같은 시스템 주요 구성 요소가 바뀔 때에는 뭔가 공개된 토론이 필요하지 않겠느냐는 말에 또 다른 데비안 개발자는 이렇게 답했더군요. 요약하면 그래 봤자 "찬성" "그걸 왜 이제서야 하느냐" "지금 당장 해라" 등의 답만 돌아온다고 합니다. 그리고 glibc 2.9와 2.10 간의 차이가 glibc 2.9와 eglibc 2.9 간의 차이보다 더 크다는 말도 있네요. 이 결정은 IRC 채널 및 오프라인 상에서 이뤄진 거라서 구글신도 잘 못 찾고 있네요.
http://www.pubbs.net/debian/200905/75800/
위쪽에 링크가 걸린 glibc 버그 4980번을 보니까 레드햇에서 해결책을 찾으라고 하니까 그제서야 뭔가 작업하는 것 같더군요. 각종 답글들을 보니까 '이건 뭐 싸우자는 것도 아니고' 하는 생각만 듭니다.
---- 절취선 ----
http://blog.peremen.name
eglibc는 glibc 사이즈
eglibc는 glibc 사이즈 줄이는 거랑 관계없는 glibc fork의 하나일 뿐이고요. (호환성을 유지한다는 것부터가 다운사이징은 불가능..) 다른 거 다 필요없고 드레퍼 그 양반을 상대하지 않아도 된다는 것만으로도 최고의 선택입니다. 성격 더러운 사람은 어디에나 있지만 아마 그 사람 상대해 본 사람이라면 거의 다 최악의 메인테이너로 생각할 겁니다. 말이 험하고 안 험하고가 문제가 아니라 큰 프로젝트를 혼자서 휘두르면서 일단 "안 하겠다"는 방향으로만 고집을 피우니.
한글 환경 발전에도 악영향을 끼쳤던 인물이죠. 기억하시는 분도 꽤 있을텐데, glibc 2.0에서 wcstombs() 따위의 멀티바이트 기능을 스펙을 잘못 이해해서 잘못 구현해 놓고서는 거의 2년동안 자기가 맞다고 고집을 피우니까 못 참은 사람들이 LD_PRELOAD로 덮어 쓰는 libwcsmbs를 만들고. 나중에 2.1에서 바로잡으면서도 자기 틀렸다는 얘기는 절대 안 하더군요. 그 뒤에도 glibc 관련된 사항은 해 보지도 않고 잘 동작한다거나 스펙이 아니다 지원 안 한다는 식의 반응이 첫 반응의 대부분입니다.
재밌네요ㅋ 원래
재밌네요ㅋ 원래 이렇게까지 깐깐한 사람이었나 싶을 정도로ㅎㅎ
Drepper씨가 gconv/iconv 작업하고 있을때 잠깐동안 테스트작업을 했던적이 있었습니다.
당시 메일링리스트로 안하고 개인메일로 여러차례 주고받았는데도 의외로 참을성 있더군요ㅋ
원화기호 사건도 생각난다는ㅋ
온갖 참된 삶은 만남이다 --Martin Buber
egcc의 전처를
답습할 것 같습니다.
긍정적으로 봐야 겠죠.
There is no spoon. Neo from the Matrix 1999.
There is no spoon. Neo from the Matrix 1999.
최근 icinga라고 nagios fork도 생겼죠
최근 icinga( http://www.icinga.org/ ) 라고 nagios ( http://nagios.org ) fork도 생겼죠
이유는 역시나 glibc, eglibc의 경우와 비슷~
댓글 달기