한소프트리눅스 2006 Server Asianux Inside 출시

다운로드는 어디에서? ㅡㅡ;;;

꼭 국산을 써줘야 하나요??? ㅡ,.ㅡ;;;;
아시아눅스에 한소프트리눅스가 인지도를 높이기 위해 꼽사리낀거 같은데요...
저는 잘 모르겠네요.

암튼, 리눅스는 외국꺼 쓰나 우리나라꺼 쓰나 별 의미가 없는것 같은데... M$를 써서 외국으로 자본이 나가는것두 아니구요. 다만 우리 리눅스업계의 역량이 낮아지겠지만요.(장기적으론... ㅠ.ㅠ)

한소프트리눅스는 깔기는 편하던데요. 윈도우같은 리눅스(?)라고 해야 하나요???

왠지 엄청 느릴것 같은...

역시 대세는 데비안 패밀리군요. 우분투 만쉐~ ^^)/

아시아 리눅스가 윈도우에서 리눅스에서의 진입장벽을 낮추는데 크게 기여했으면 좋겠습니다. 서브컴에 리눅스 깔아놨더니 누나가 불여우 아이콘도 못찾네요;; 엉엉엉

그렇게 구식인 RPM 방식이 전 세계에서 가장 많이 상용화되어 이용하는 리눅스 패키징 방식이랍니다.

RPM 의 압박이니 KDE 의 압박이니 하는것도 뭐든 나누기 좋아하는 사람들의 자기위주의 사고방식 때문일 뿐입니다. GNOME 도 만약 좋류가 나뉜다면 또 그걸 가지고 나눌겁니다.

window 랑 리눅스 나누고
리눅스 안에서 또 RPM , 비 RPM 으로 나누고
그 안에서 또 KDE 나누고 GNOME 나누고.

이제 또 뭘 나눌지 궁금할 뿐입니다.

rpm 이건 아니면 그 밖에 뭐건 결국 그 사람의 취향일뿐 어느게 더 좋고 나쁘고를 따질 객관적이고 합리적인 근거를 대는 사람은 지구상 어느곳에도 없습니다.

참고로 IBM AIX쪽도 rpm을 쓰더군요

패키지 관리만 잘하면 되지 머가 신형방식이고 구형방식이고

구분을 하기 어려울 듯 생각됩니다.

RPM의 의존성 미해결 문제를 취향으로 보시다니.. 다크 슈테펜님의 불만은 그 의존성 문제 같은데요.. 사실 yum과 같은 손 쉬운 방식에 비교하면 많이 불편한 부분이 있는 건 사실이죠.

1.

yum을 통한 업데이트 및 설치등이 느린것이지 rpm이 느린건 아니죠. ^^ apt를 통한 rpm업데이트의 경우 파일트리를 읽는 방식이 데비안의 apt-get과 거의 동일하기 때문에 이것이 그 어떤 특정부분의 문제라고 볼 수는 없는겁니다. yast의 rpm 파일트리를 읽는 속도는 오픈 수세에 이르러서는 거의 정점에 이른듯 보이네요.

2.

데비안의 페키징 시스템인 deb(정확히는 위에 언급된데로 dpkg)로도 의존성이 해결 안되기는 마찬가지가 아닐까요? ^^ rpm만이 의존성 문제를 일으키는것은 아닙니다. 단지 그와 연계하여 사용할 수 있는 패키징 어플리케이션들의 능력 여하에 따른 문제지요.

rpm이 느린것은 아닙니다.하지만 패키징 관리하는 방식은 yum은 apt-get만큼의 속도도 느릴뿐더러 그리고 사용하는 방법도 복잡합니다.물론 dpkg를 이용해서 설치할려고 하면 의존성 에러가 나은 것은 사실입니다.
하지만 의존성 에러가 나도 다시 그 의존성을 메꾸기위해 yum과 apt-get 둘중 하나를 사용해야 하나다면 저는 apt-get입니다.
물론 페도라에서도 apt-get을 사용할수는 있겠지요
하지만 apt-get 앱티튜드 시냅틱을 통한 편리함에는 못한것 같습니다.
rpm자체는 레드햇에서 보안하면서 여러가지 안정적으로 잡아 가겠지요.
하지만 YUM을 통한 업데이트나 프로그램 설치는 데비안의 apt-get 앱티튜드 시냅틱의 편리함과 속도를 따라 갈려면 아직은 멀었다고 생각합니다.그래서 rpm이 싫은 겁니다.
PS:수세는 아직 사용해 보지 못했습니다만 전에 맨드레이크나 그런것의 경험을 비추어 본다면 글쎄요...
PS2:개인적인 잡담이 이렇게 파장이 커질줄은 몰랐습니다.죄송스럽게 생각합니다.

그럼 apt-rpm을 사용하세요. -_-a; 근데 fc4 접어들면서 apt-rpm의 기본 레포지토리를 제공하고 있지 않기 때문에 yum을 쓰는게 낫지요. 환경도 많이 좋아졌구요. 속도문제는 파일 리스팅처리 문제로 늦기는 합니다. rpm헤더를 한번에 받아오느냐 아니면 각 파일 하나하나마다 헤더를 받아오느냐의 차이라는거지요. 그 외에는 뭐 똑같아요.

p.s

근데 yum은 빨라야하고 apt-get은 간단해야하나요? -_-;;

으음.. 저는 yum도 사용해 보고 apt-get, 시냅틱, 앱티튜드 모두 사용해 보았습니다.

그런데 역시 apt-get,시냅틱,앱티튜드 조합이 제일 좋습니다.

특히 aptitude 를 주로 쓰는데 그 이유는 패키지 설치의 의존성뿐이 아니라
패키지 제거시의 의종성도 처리해 주기때문이죠.
속도는 제가보기에 yum 보다 aptitude 가 더 느리기도 합니다.
그러므로 저는 속도냐 하는건 중요하게 생각하지 않습니다.

그런데 yum 을 사용해보니 패키지의 부재 라고나 할까?
예전 학교 실습실에서 한 컴퓨터에 리눅스를 설치해서 썼습니다.
서버 구성 하는 것을 한번 연습해보려 설치한것이지요.

그당시 막 yum 이란것을 접해서 해보려 했습니다.
그런데 페도라는 어떨지 모르겠지만
레드햇 9 는 평가판이라 그런지 업데이트가 정말 느리더군요.
php 를 업그레이드 하려 해보았지만 yum 저장소에는 php 버전이 그 당시 나와있던 것보다 한참 낮은 버전이었다고나 할까.. 처음 시디로 설치했다면 몰라도.. 업그레이드하가위한 서버 저장소마저 버전이 시디와 그대로라면..
그리고 시스템엔 깔려있는데. 저장소엔 없는 ㅍ키지도 있더군요..
그에비해 데비안,우분투,페도라 같은 커뮤니티에 의해 개발되는 배포판은 패키지의 적용 기간이 매우 짧습니다.
금방금방 들어오고 하니까요..(근데. 데비안은 -_-a)
레드햇,페도라의 경우 처음 설치시의 릴리즈 버전들은 매우 최신입니다만.
그 후 업그레이드 같은 부분에서 매우 빈약하더군요.
설치후 어떤 프로그램을 업데이트 하거나 추가설치하려니 패키지가 저장소에 없어 yum 이 아닌 rpm 을 받아서 설치해야 했던 기억이 납니다..(php)
그래서 rpm 을 받아서 설치해보려 했더니. 의종선에서 서로 cycle 처럼 걸려있어서 (즉 거미줄처럼 얽혀있어서...) 결국 포기했던 레뎃 9 버전입니다..
RHN 이라는 좋은 솔루션이 있지만 '돈' 이라는 문제와 또한 업데이트 하는데 여기저기 툭툭 태클이 자주 들어오더군요..
RSA 키 인증부분에서 다음으로 넘어가지 않는둥..

한소프트리눅스도 초보자가 쓰기에는 매우 좋은 배포판임에는 틀림없습니다.
소프트엑스포에서 한창 이벤트행사하고 난리칠때 가서 실컷 구경해보고 왔습니다..
이건 그 다음버전이겠군요 :)
그러나 패키지가 소수라는 것이라는것니다.
그렇다고 페도라나 레드햇의 yum 저장소를 무작정 쓸수도 엇는 노릇 아닙니까?
페도라나 레드햇이야 전세계적인 규모와 사용자들의 참여로 패키지가 빨리빨리 들어온다지만.

이제서야 진출해서 규모도 아직 조그마한 한소프트리눅스는 페도라같은 사용자들의 패키지 포팅을 기대할수 없는 노릇 아닙니까.
홈페이지 가봐도..자료실, 업데이트 공지 같은 부분을 봐도 역시 데비안같은 업데이트와는 비교가 됩니다.

그런 점에서 저는 국내 배포판들의 기술력은 좋지만 역시 사용자들과의 소통이 원활하지 않는다고 생각합니다. 겨우 게시판 운영해서 그걸로 사용자들과 커뮤니케이션 했다고 하는건 .. 않좋다고 생각하네요.
이제는 사용자만 포섭할게 아니라 레드햇처럼 개발자들도 끌어당길때라고 봅니다만...;

RPM 이 데비안 패키지보다 못하다거나 혹은 그 반대라는 의견은 그냥 개인적인 취향에서 나오는 말들 같습니다.

데뱐의 장점으로 얘기되는 의존성 문제 해결은, RPM에서 yum이나 apt-rpm을 이용하면 된다고 보고요...

기업에서 RPM을 선호하는 이유중 하나는, 레뎃이나 수세등 비교적 큰 규모의 배포판 패키징 방식이 RPM일 뿐만 아니라, LSB의 표준 패키징 방식으로 지정되어 있기 때문일 겁니다.

반면에 리눅서들은 젠투나 데뱐등 다양한 배포판을 사용하는만큼 패키징 방식도 다양하게 사용하고 있지요.

추후 또 어떤 패키징 방식이 나타날지도 모르는거고, 그 때마다 논란이 있을 텐데요... 뭐가 좋네 나쁘네는 그냥 객관적으로 비교할 수 있는 내용 또는 수치가 아닌 이상 안 했으면 하는 바램입니다.

선호도 차이일뿐. (전 개인적으로 RPM 을, 그리고 apt-rpm 을 선호합니다.)

덧붙여서, 아시아눅스는 표준은 아니죠. 부요도 사실 표준이라고 보기에는 여러가지로 복잡한 문제가 있고.... 각자 장단점이 있을꺼고, 결국엔 경쟁력이 있는(기술적이든, 마케팅 측면이든, 아니면 제 3의 무엇이든) 놈이 살아남겠죠. 이런 경쟁, 저는 좋게 생각합니다.

RPM이던 DEB던 아니면 젠투의 그것이던 사용자가 어떤것이 편하냐 문제일 뿐 그것이 특별히 문제가 있다거나 그런것은 아닐것입니다.사용자가 어떤 선택을 하느냐 하지만 중요한것은 패키징 방식을 선택하는 것도 중요합니다만 앞으로 리눅스 장래를 위해서는 패키징 방식도 점창 통일 되어야 한다는 겁니다.사용자를 위해서나 그리고 개발자를 위해서나
지금 현재 리눅스 프로그램에서 얼마나 많은 패키지를 내걸어야 합니까...?
먼저 소스 타르볼,RPM 이것도 레드햇 수세 맨드리바 등등 DEB 데비안 등등 젠투 등등 이렇게 됩니다.
사용자는 어떤 패키징을 선택해야 할것인지 선택 혼란이고 개발자에게는 시간 낭비며 리소스 낭비입니다.
윈도우즈와 맥오에스의 장점이라고 한다면 역시 단일화된 프로그램 배포가 아닐까 합니다.
윈도우즈는 설치파일 클릭하거나 아니면 파일 복사면 끝이고 맥오에스도 파일복사 하거나 설치파일 클릭하거나 아니면 DMG안에 패키징된 설치 프로그램을 사용하거나
다른 운영체제에서는 어떻게 패키징 할것인지 그냥 개발자가 알아서 한가지 방식만 고집하면 됩니다만 리눅스는 그렇지가 못합니다.
물론 LNGTV가 좋아서 그것으로 통합하거나 아니면 별땅 세개 TV가 좋아서 그것으로 통합하거나 소냐 TV가 좋아서 그것으로 통합하거나
유니크한 뭔가로 보완해 나간다고 하면 지금 이런 논쟁도 필요 없겠지요..개발자 들을 위해서나 아니면 정확한 패키징 정책이나 아니면 리소스 낭비를 줄이기 위해서도 개발자들이나 리눅스 표준(?)에 관련된곳에서 하루 빨리 정해야 할것입니다.리눅스 한가지를 놓고 보면 너무 많은 배포판에 너무 많은 패키징 방식이 있는게 오히려 문제이기 때문일겁니다.
개발자들이나 리눅스 예찬론자들은 이것이 선택의 자유라고 생각할수도 있겠지만 소비자 입장에서는 혼란입니다.
앞에서 패키징 방식의 비교는 의미 없다고 하셨는데 리눅스가 더욱 발전할려면 패키징 방식은 간소화 되어야 하고 또한 이 과정에서는 비교는 필연적이라고 생각합니다.그것이 객관적이던 주관적이던..
즉 결론적으로 배포판에 대한 사림 문파간에 의견충돌은 불필요한 것일수도 있습니다.하지만 패키징방식에 대한 비교는 불필요한 것이 아니라는 겁니다.
PS:약간 횡설 수설했네요..

레드햇 쓰다가 거의 2년 전쯤 데비안으로 옮겼습니다. 왜 옮겼느냐..
당시에 xfig를 깔려고 했는데 libc6 신버전을 요구했습니다.
그런데 libc6 신버전을 깔려고 하다 보니 일단 지워야 하는데, libc6 구버전에 의존된 패키지가 하나 둘이 아니더군요.
의존성 있는 패키지 다 지우고 libc6신버전 깔고 xfig 깔고...
일련의 작업들이 당시 레드햇에서는 간편하지 않았었죠.
제가 사용하고 있던 레드햇을 업그레이드 하는 것 보다 더 신버전의 레드햇을 새로 까는 것이 거의 유일한 대안이었습니다.
(요새는 많이 편해졌나요? 페도라가 생기면서 많이 편해졌다는 이야기를 듣긴 했습니다.)
그래서 데비안으로 넘어왔습니다.
데비안에서는 패키지 관리자가 하는대로 걍 따라가면 해결되더군요. 저는 synaptic을 사용합니다.
xfree4.3 -> Xorg 6.8 같은 꽤 큰 규모의 업그레이드도 신뢰성 있게 해결해 줍니다. 사용자는 정말로 클릭과 y버튼만 해주면 됩니다.

말씀하신것 처럼 합쳐진 표준을 위하여 아시아리눅스 라는것이 만들어 졌고 이 포럼의 주제가 되는 정보로 올라왔습니다. 그러나 분명 그에 반대하는 의견을 가진 사람들이 더 좋은 표준이라며 내세우는것이 비교적 RPM 과 완전 대칭되는 데비안기반 시스템입니다.

어느쪽이 어느쪽을 위해서 무얼 버리겠습니까.

사용자는 선택의 폭이 넓어야 합니다. 그래야 서로 경쟁하며 발전하는거지요. 허나 서로의 장점을 인정하고 칭찬하지 않고 헐뜯는다면 발전은 조금은 더디게 되지 않겠느냐는 거지요.

윈도우와 맥OS 의 장점은 제 생각인 단일화된 프로그램 배포가 아니라 손쉬운 인터페이스 라고 생각합니다. 윈도우즈 자동업데이트로 프로그램 업데이트가 되듯 아쉽긴 하지만 yum 이나 apt-get 모두가 자동 업그레이드를 지원합니다. 그럼 이제 서로가 서로의 장점으로 판단하여 yum 은 apt-get 의 빠른 업그레이드와 안정성을 본받으면 되며, apt-get 이나 데비안 설치시스템은 가급적 보기 편안하고 접근이 편한 RPM 방식이나 yum gui 인터페이스를 본 받으면 되는 것이라고 봅니다.

전 소비자 입장에서 혼란이라고 보지 않습니다. 공산주의가 아닌이상엔 사람에겐 선택의 자유가 있는것이고 또 그 선택에 대해서 왈가왈부 할 자격은 없습니다. 단지 의견으로 개진할 순 있겠지만 자신이 아는것이 사실이고 진리라고 할 수는 없는 것입니다.

네 비교는 필연적입니다. 근데 첨에 비교가 아니라 "RPM, KDE 의 압박" 이라고 하셨잖아요.. :twisted:

과연 여러 패키지 설치판을 걸어 놓고 소비자의 선택이라고 말할 수 있을까요
거기서 안정적으로 설치가 가능한것은 다 걸어 놓는다고 해도 역시 1개 또는 2개 정도만 설치가 가능할뿐이지 나머지는 설치해서도 설치할필요도 없는 파일 아니었던가요...?
소비자의 선택을 위해서 RPM 레드햇 수세용 맨드리바 용 걸어 놨다고 한다면 어느것을 선택하실껀가요 레드햇이면 레드햇용만 설치할 것이고 수세용이나 맨드리바용은 설치될수도 있겠지만 설치가 안될수도 있습니다.이런것을 소비자 선택이라고 할수 있는 건가요...?
윈도우즈나 아니면 맥오에스와 차이를 든것은 바로 이점입니다.설치 방법이 여러가지라고 해도 대부분의 윈도우즈나 맥오에스에서는 다 적용되는 설치 방법입니다.
개발자가 단순 복사 설치본과 그리고 설치 인스톨러를 제공한다고 한다면 이것은 소비자 선택입니다.어짜피 둘다 설치가 가능하고 동작이 가능할테니까요...
그러나 리눅스에서는 다르지요 레드햇 수세 맨드리바 데비안 젠투 다 거의 모든 리눅스에서 적용이 가능한가요...? 이것이 소비자 혼란이라는 겁니다.
그리고 처음에는 제가 RPM KDE압박이라고는 했습니다만 점차 RPM DEB의 비교로 쓰레드가 넘어 갔으며 이후 마지막에는 두개 패키지의 비교는 무의미 하다고 결론 내리시는 분들에대한 제 생각입니다.
그리고 아시아눅스가 표준으로 만들어 졌다고 하셨는데 표준이라고 인정합시다.하지만 그를 지원하는 패키지가 적고 또한 사용자 층이 적다면 표준이 될수 있을까요 아무리 자신들이 표준용으로 만들었다고 해도 대다수의 사람들에게 적용을 받지 못하고 환영을 받지 못한다면 표준으로서의 자격 미달입니다.
같은 이유로 인터넷 익스플로러나 액티브액스도 표준으로 인정 못 받는 것은 아닌가요...?
소비자가 정말 작동할수 있는 방법을 많이 제공할때 그게 진정한 소비자의 선택이고 또한 리눅스 개발자도 역시 통합된다면 다른 배포판을 위한 패키지를 제작하는 시간에 코드를 한줄 더 짤수 있을겁니다.

패키징방식과 배포판과는 항상 같은 것은 아니겠지요.... :twisted:
패키징 방식의 통합과 배포판의 통합과는 엄연히 다른 의미입니다.
어느 누구도 윈도우즈 9X와 윈도우즈 엔티계열을 같다고 말하는 사람은 없을 것입니다.

패키징 방식의 통합은 단순히 포맷문제만 해결하면 될 정도로 단순한것은 아닙니다.

정책상 충돌나는 부분이 많습니다.

가령 어느쪽 패키지 트리에서는 안정적이고 보수적인 패키지 구성을 원해 낮은 버젼위주의 패키지 트리를 갖고 있는데, 패키지 방식( 단순히 파일포맷의 통일?? )이 통일되었다고, 비교적 빠른업뎃이 되는( 포티지 처럼 ) 트리의 패키지를 가져다 쓴다고 치면 많은 의존성에러가 날 것입니다. 그럼 패키지간의 의존성 정의를 잘 해놓으면 될까요? 그렇진않은거 같습니다.

가령 xfree를 쓰는 배포판에서 xorg에만 있는 기능을 이용에 의존적인 다른 배포판의 패키지를 가져다 쓸 수 있을까요? 그럼 의존성 때문에 결국 배포판 전환이 되는 일이 발생할수도 있습니다. 배보다 배꼽이 더 큰경우죠..소프트웨어 하나 업데이트하려다가 OS대부분을 업데이트 해야하는경우가 생길수도 있으니..

어떤분이 맥os와 윈도우 얘기를 예로 들으셨는데
제 생각에 리눅스와의 차이점은 패키징방식의 포맷문제도 있지만

리눅스는 패키지의 maintainer와 developer가 다르다는것과 리눅스쪽의 패키지의 특성상 다른 패키지와의 의존도가 높다는 두가지 문제 때문인것 같습니다.

둘은 어케보면 얽힌 문제일수도 있는데,
오픈소스쪽의 프로젝트들을 보면 다른 프로그램들과의 연동하는 부분이 무척이나 많은것 같습니다. 반면 윈도우(맥은 잘모르니 패스 =3=3 )쪽은 보면 자신이 의존한 패키지들은 대부분 직접 배포하거나 MS에서 관리하는 패키지들이 대부분입니다.그래서 의존성 문제를 들 겪는거겠죠. 직접 배포하는것들은 당연히 의존성문제를 겪지 않을것이고, MS에서 관리하는거야 대부분의 OS에 항상 동일한 형태로 깔려있을것이기 때문입니다.

아파치나 php같은것만 보더라도 .configure 스크립트에 옵션을 어케주느냐에 따라 의존성이 걸리는 패키지가 다양한데, 그 패키지들 또한 배포판마다 제공되거나 안될수도 있고, 다른 종류의 패키지들을 제공하는 경우도 많습니다. 물론 대부분 소스레벨에서는 호환이 되죠. 그래서 소스컴파일을 하는경우에는 대부분 의존성이 문제되지않습니다( 그래서 포티지가 이득이 많은것 같습니다. ) 하지만 RPM같이 바이너리기반의 패키지에서는 의존성이 걸쳐지는 패키지들의 범위가 크면 클 수록 그 패키지 조차 의존성이 걸리고 걸려서 끊임없이 될 경우가 많다는것입니다. 물론 RHEL은 RHEL쪽 트리끼리 잘 호환이 되고, Fedora는 core씨리즈끼리 트리가 잘 호환이 바이너리 호환이 잘 되는경우들이 있는데 그건 해당 배포판의 전반적인 패키지 관리정책이 크게 다르지 않기때문입니다. 하지만 패키지트리의 성격이 상이한 트리에서 가져온 바이너리를 설치한다고 했을때 그 각각 패키지트리에서의 maintainer들이 의존성 정의를 잘 한다고 해결된다고 보지않습니다. 트리의 전반적인 버젼과 패키징 정책을 통일하기전엔 의존성문제는 해결되기가 힘든것 같습니다( 다른 패키지트리간의!! )

즉, 패키징 방식의 통합은 불가능하다고 봅니다.( 포맷만 통일하면 되는게 아니므로 )

단지 작은 배포판들이 자발적으로 LSB같은걸 통해 패키지 포맷만이 아닌, 패키지 트리의 전반적인 버젼( glibc나 openssl, gcc 같은것들은 바이너리 기반 패키지하에서는 버젼이 틀리면 참 난감합니다. )을 통일 시키는 방법밖에 없다고 생각합니다.[/b]

인정할수 있는... 좋은 매너를 가지셨군요!!!

하여간에... 이런 상황이 문제인건 다들 아는데... 딱히... 뭔가... 해결책이 없는것 같네요!!!

불현듯... 한가지 생각이...

인스톨쉘드와 같은 리눅스용 프로그램이 나오면... 어떨지???
설치프로그램을 만들어주는 프로그램이 다양한 환경을 고려하면...
개발자 및 배포자는 다양한 환경을 고려하는 수고가 좀 없어지지 않을까요?

우분투 만쉐~ + emerge 만세 !!! + 젠투 만세 !!! + 젠투 만만세!! = 리눅스 만세!~

일단 사실 요즘의 redhat 계열 배보판들은 잘 모르겠습니다만,
redhat 계열에선 불과 한 작년만 해도 libc 업데이트가
쉽지 않았던 것으로 압니다. ;;
그에 비해 debian이나 gentoo의 경우 상당히 쉽게 가능했죠.

그리고 dependency 정보에 대한 글들을 가끔 접하게 되는데,
( 무엇을 보고 dependency를 체크하는지 등등요. )
gentoo > debian > redhat 정도로 상세한 정보를 가진듯하더군요.
뭐 저야 자세히 모르겠고, 정보야 어쨌든 debian 쓸거지만 :twisted:

저는 알짜, 와우, 그리고 코어 , 현재는 한소프트
이렇게 넘어 왔습니다....

멘처음 쓰신 분의 글을 읽고 여기도 한소프트 쓰는 사람있다..라고
말씀 드리고 싶었습니다.....

그리고....저는 한번 깔때마다 깨끗하게 한번씩 미는 타입인데...
밀고 다시 사용할때 ..가장 간단하게 쓸수 있는건 역시...
한소프트 같은 국내 배포판이 가장 좋았다고 단연코 말씀 드리렵니다.
페도라 한번 써보려다.....깔고 몇시간 안에 다시 지울때는 아픔이
있었지요....

이제 워크스테이션 버젼이 다시 나오면 또 한번 구매를 해야겠군요...

ps.:
그렇게 glibc 같은 페키지를 업그레이드 해야할 일이 많습니까?
ps2:
저는 최근까지 한텀 갔은 페키지를 사용해야 할 때는 와우의 패키지를
찻아 다녔답니다.... 이제는 쓸수 없지만....