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

bokkwonsu의 이미지

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

http://www.haansoftlinux.com/business/asinux_info_05.php

오늘 한소프트에서 한소프트 2006 출시했다는 이메일이 왔네요

한소프트리눅스 사이트(http://www.haansoftlinux.com)가보니까

한소프트 리눅스 2006 설치 스크린샷있는데

언듯 보기에 윈XP인줄 알았습니다

제어판도 윈도우랑 비슷합니다

패키지도 HSUpdate로 자동으로 설치/업데이트되고

리눅스용 한글2005에 대한 제품정보도 있었습니다

조만간 윈도우 안보고 살 날이 올꺼같네요

근데 왜 한소프트 리눅스쓰시는 분이 별로 없죠?

전 한소프트리눅스가 가장 정이 가던데

참, ActiveX지원되는 웹브라우저 지금 모질라에서 개발중인가요?

너무 개인적인 말이 많아서 뉴스라고 하기엔 좀;;

버려진의 이미지

많이 써주고 밀어주고 싶지만 RPM이라는 익숙치 않은 것이 걸려요.

저번엔 뭐 설치하려고 했는데 없어서..

컴파일하려고 했는데 의존성이 좌르륵 걸리고 -_-

(예를들면 xchm이라던지..)

그래도 좋아보이네요. ^^

ps. 저번에 코어리눅스때 받았던 자주색 티셔츠를 한소프트 티셔츠로 바꿔주면 좋겠... (퍽퍽)

bokkwonsu의 이미지

이제 국산 리눅스에선 한소프트만 명맥을 잇고 있는게 맞죠?

M$싫어서 리눅스 관심갖았는데

되도록이면 국산 제품을 써주고 싶은 맘이들거든요

여기는 거의 다 우분투 유저인거 같아요 ㅎㅎ

근데 서명에 이미지는 어떻게 넣는건가요?

환상경의 이미지

복권수 wrote:
이제 국산 리눅스에선 한소프트만 명백을 잇고 있는게 맞죠?

와우리눅스
눅스원

등이 아직 있습니다......라고 하지만 뭐.....

==================================================================
정체된 일상.... 계기를 만들어야 하는데........
BLOG : http://khmirage.tistory.com/

fooo의 이미지

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

dragonkun의 이미지

엔드유저들에게 친숙하게 가려면 어쩔수 없는 선택인지는 몰라도
너무 윈도우 클론 같은 UI를 보여줘서..안타깝네요..

그래도 완성도는 꽤 높은 듯 보이네요..
아시아권에서의 레드햇, 수세 같은 존재가 되었으면 좋겠군요~

PS. 마지막에 ORANAVI를..ORAVI..라고 읽고 피식했네요.. :oops:

Emerging the World!

냐옹이의 이미지

복권수 wrote:
이제 국산 리눅스에선 한소프트만 명맥을 잇고 있는게 맞죠?

M$싫어서 리눅스 관심갖았는데

되도록이면 국산 제품을 써주고 싶은 맘이들거든요

여기는 거의 다 우분투 유저인거 같아요 ㅎㅎ

근데 서명에 이미지는 어떻게 넣는건가요?

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

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

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

------------------------
냐옹~~

다크슈테펜의 이미지

RPM과 KDE의 압박...ㅠ0ㅠ;;

인생이란게 다 그런게 아니겠어요....? 뭘(?)
http://schutepen.egloos.com

yglee의 이미지

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

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

GunSmoke의 이미지

적어도 KLDP내에서 만큼은 특정 배포판에 대한 선입견이 없었으면 합니다.

大逆戰

wpcasper의 이미지

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

환상경의 이미지

gnoyel wrote:
왠지 엄청 느릴것 같은...

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

꽤 뛰어납니다.
서버환경에 필요없는 멀티미디어 패키지같은걸 모두 생략하고 오로지 서버과련 패키지만 들어있어서 퍼포먼스면에서는 꽤 좋은 성능을 냈습니다.
그야말로 서버....죠....
그리고 레드햇보다는 가볍더군요.......~ 히힛~

==================================================================
정체된 일상.... 계기를 만들어야 하는데........
BLOG : http://khmirage.tistory.com/

bokkwonsu의 이미지

환상경 wrote:

꽤 뛰어납니다.
서버환경에 필요없는 멀티미디어 패키지같은걸 모두 생략하고 오로지 서버과련 패키지만 들어있어서 퍼포먼스면에서는 꽤 좋은 성능을 냈습니다.
그야말로 서버....죠....
그리고 레드햇보다는 가볍더군요.......~ 히힛~

한소프트 리눅스 2006 벌써 구하셨나요?

서버 발표했으니 워크스테이션 배포판도 곧 나오겠죠? ㅎㅎ

설치해본 리눅스가 다 레드헷 계열이라;;;

RPM이 그렇게 구식인지 몰랐네요;;

리눅스 입문 책봐도 RPM얘기밖에 없던데

그나저나 아시아눅스 있는데 머하러 부요만들어서

이러다나 국내 표준 두개 되는거 아닌지;;

환상경의 이미지

복권수 wrote:
환상경 wrote:

꽤 뛰어납니다.
서버환경에 필요없는 멀티미디어 패키지같은걸 모두 생략하고 오로지 서버과련 패키지만 들어있어서 퍼포먼스면에서는 꽤 좋은 성능을 냈습니다.
그야말로 서버....죠....
그리고 레드햇보다는 가볍더군요.......~ 히힛~

한소프트 리눅스 2006 벌써 구하셨나요?

서버 발표했으니 워크스테이션 배포판도 곧 나오겠죠? ㅎㅎ

설치해본 리눅스가 다 레드헷 계열이라;;;

RPM이 그렇게 구식인지 몰랐네요;;

리눅스 입문 책봐도 RPM얘기밖에 없던데

그나저나 아시아눅스 있는데 머하러 부요만들어서

이러다나 국내 표준 두개 되는거 아닌지;;

워크스테이션 버전은 아시아눅스 인사이드로 나오는것이 아닌걸로 알고 있습니다.
그리고 아시아눅스 사용해보고 싶으신분들은 강변역 테크노마트 지하 1층 한소프트 체험관이 있습니다. 거기 입구서 맨 오른쪽 안쪽에 아시아눅스가 설치되어 있으니 경험해보고 싶으신분들은 한번씩 가서 사용해보세요 ^^;;
그런데 서버라서 별반 할것은 없을듯....

==================================================================
정체된 일상.... 계기를 만들어야 하는데........
BLOG : http://khmirage.tistory.com/

notnull의 이미지

복권수 wrote:
RPM이 그렇게 구식인지 몰랐네요;;

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

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

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

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

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

1day1의 이미지

그런데, RPM 이 구식이라는 말이 어디서 나온것인가요?
언급된 내용이 없네요.(잘못 본것인가?)

전 페도라든 데비안이든, 요즘 나오는 것들은 다 좋던데요.

그런비교는 다 옛날이야기인 것 같습니다.

요즘 것들은 윈도우도 훌륭하고, 리눅스도 그렇고, Mac OS 도 그렇고, 다 좋습니다.
제가 낙관(?)주의 인가요?

F/OSS 가 함께하길..

다크슈테펜의 이미지

notnull wrote:
복권수 wrote:
RPM이 그렇게 구식인지 몰랐네요;;

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

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

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

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

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


제 의견 때문에 그러시는 것 같은데 물론 인정합니다만 저는 그냥 개인적인 이유로 RPM과 KDE가 싫기 때문에 개인적인 감정을 적어 놨습니다.이 두가지 이유로 설치하기가 싫어 진다고 써놨을 뿐입니다.
RPM을 싫어 하는 이유는 우선 예전 의존성 문제 때문이고 두번째 YUM을 통한 업데이트를 지원하지만 뭐 이것도 배포판 마다 다르겠지만 페도라코어 기반이라면 YUM을 통한 지원이겠지요 하지만 YUM을 통한 업데이트는 데비안이나 우분투 사용자라면 얼마나 속도가 느리고 적용방식도 다르다는 것을 아실겁니다.이것때문에 RPM을 싫어 하는거고 KDE는 예전에 꾸밀려고 노력해도 복잡하고 그리고 심플하지않고 또한 폰트도 이상하게 보이고(폰트렌더링을 가장 중요시합니다.개인적으로)해서 KDE세팅도 며칠하다가 그냥 포기하고 그놈으로 갔습니다.그리고 강력한 어플은 많으나 개인적으로 가지고 놀기에는 KDE어플은 수적으로 부족했습니다.저에게는...개인적으로 잡담식으로 적어 놓은게 비난 받아야 하는건지 오늘 처음 알았습니다.
강력한 홈엔터테이먼트 시스템이라도 그냥 평소에 워크맨이나 만지작거리고 홈엔터테이먼트 시스템에는 관심없는 사람들에게는 그것이 설사 강력하다 하더라도 워크맨만 못한법입니다.

인생이란게 다 그런게 아니겠어요....? 뭘(?)
http://schutepen.egloos.com

정태영의 이미지

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

얼마 전에 이 블로그 저 블로그를 다니다가 발견했던 글입니다 :)
http://lastmind.net/archives/001070.html

관련해서 생각나길래 한 번 링크 걸어봅니다... 저도 사실 레드햇계열을 그다지 좋아하지는 않지만... (데비안 계열은 안써봐서 노코멘트입니다)

예전 rhn 이 등장하기도 전의 레드햇을 사용했던 사람들이라면 rpm 에 대한 반감이 어느정도 있을 수 있다고 생각합니다... 뭐 하나 깔려고 rpmfind.net 에서 찾아서 이제 됐겠지 하고 rpm -Uvh ... 을 치면... 주루룩 떨어지는 의존성들... 하나하나 손으로 찾아서 받은 담에 또 rpm -Uvh ... 을 치면 떨어지는 새로운 의존성들 -_-;;;

현재야 apt-get 이나 yum , up2date 등이 있으니 얘기가 다르지만요...

지금 rpm 의 문제라면 너무 많은 rpm 기반 트리가 존재한다는 점이 아닐까 싶습니다...

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

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

^_^의 이미지

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

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

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

----------------------------------------------------------------------
웃는 얼굴 헤죽 헤죽

다크슈테펜의 이미지

할수 있다는 것과 하고 싶다는 것은 엄청난 차이가 있지요..
물론 소스 컴파일로 프로그램 설치하던 아니면 RPM으로 설치하던 아니면 deb로 설치하던 프로그램이나 라이브러리 패키지 관리 잘하면 됩니다.물론 하드웨어가 어쩔수 없는 상황이라면 저도 어쩔수 없겠지요.
하지만 할수는 있습니다.하지만 하고 싶지는 않습니다.너무 구차니즘에 빠진 건가요..

인생이란게 다 그런게 아니겠어요....? 뭘(?)
http://schutepen.egloos.com

coyday의 이미지

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

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

북한산(X) 삼각산(O) 백운대(X) 백운봉(O)

정태영의 이미지

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

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

제가 링크건 곳은 읽어보지 않으셨나보군요 ㅠ_ㅠ

Quote:
그리고 cyclic dependency가 있으면 update하기가 불편해지는 점 (내가 기억하고 쓰는 rpm command line option은 'rpm -qa'와 'rpm -Uvh' 밖에 없기 때문일지도) 이었다. 하지만, 데비안에서도 이러한 문제를 pakaging system인 dpkg가 해결하는 것이 아니라, apt가 해결하는 것이란 것은 rpm와 dpkg의 비교에서 항상 사람들이 혼동하는 사실중의 하나다.

세라비 님의 블로그에서 인용한 내용입니다...

rpm + yum 혹은 rpm + apt 의 조합을 통해 사용을 하는 것인데... rpm 과 yum 을 비교를 하는 것 자체가 좀 잘못된 듯 싶습니다...

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

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

ydhoney의 이미지

1.

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

2.

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

rekcuf의 이미지

예전 어떤 분의 말씀처럼 문파(?)간의 충돌은 의미가 없지요.
150여 개(맞나요?)나 되는 배포판들의 다양성은 각각마다 특징과 장단점이 있으니 자기에게 맞는 것을 고르면 되는 것 뿐이지요.

rpm 방식의 패키지 관리는 모든 분들이 인정하듯이 apt-get을 쉽게 쓸 수 있는 데비안 계열에 비하면 불편한 것은 사실입니다. 저도 아직 초보이긴 하지만 의존성의 짜증때문에 데비안 계열로 넘어왔고요... 하지만 rpm 방식이래도 RHN과 같이 중앙에서 유지 관리해 준다면 전혀 불편하지 않죠.
단, 서비스에는 공짜가 없으므로 돈을 지불해야 하니 개인들에게는 먼 얘기고요.
(한소프트는 아직 평가판에도 보안 업데이트를 해 주던 것 같습니다).

이글의 원 제목은

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

인데, 덧글들이 좀 다른 방향으로 간 것 같네요.
한소프트 리눅스의 서버버전 얘기이긴 하지만, 데스크탑버전쪽으로도 지속적인 발전이 계속 있어서, 저같이 맨 처음 접하는 리눅스가 한소프트리눅스인 사람들이 많아졌으면 좋겠습니다.
사실 윈도우에서 데비안같은 배포판으로 바로 넘어오는 것은 거의 불가능하지 않나요? 그런 면에서는 한소프트리눅스에 정말 최고의 존재의 의미가 있지 않을까요!!!

# apt-get install HOPE

다크슈테펜의 이미지

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

인생이란게 다 그런게 아니겠어요....? 뭘(?)
http://schutepen.egloos.com

ydhoney의 이미지

Yum - fc3, 4의 yumex, fc5에서 기본으로 들어갈 pup, 그리고 gnome interface를 위한 gnome-yum(줄여서 gyum)

이정도면 충분하지 않을까요?

이미 apt-rpm도 synaptic을 이용한 gui 패키징 환경을 사용할 수 있기도 하구요.

우선 뭐든지 제대로 사용해 보는것이 중요할 듯 합니다. :-)

다크슈테펜의 이미지

ydhoney wrote:
Yum - fc3, 4의 yumex, fc5에서 기본으로 들어갈 pup, 그리고 gnome interface를 위한 gnome-yum(줄여서 gyum)

이정도면 충분하지 않을까요?

이미 apt-rpm도 synaptic을 이용한 gui 패키징 환경을 사용할 수 있기도 하구요.

우선 뭐든지 제대로 사용해 보는것이 중요할 듯 합니다. :-)

Quote:

강력한 홈엔터테이먼트 시스템이라도 그냥 평소에 워크맨이나 만지작거리고 홈엔터테이먼트 시스템에는 관심없는 사람들에게는 그것이 설사 강력하다 하더라도 워크맨만 못한법입니다.

:D

인생이란게 다 그런게 아니겠어요....? 뭘(?)
http://schutepen.egloos.com

ydhoney의 이미지

다크슈테펜 wrote:

Quote:

강력한 홈엔터테이먼트 시스템이라도 그냥 평소에 워크맨이나 만지작거리고 홈엔터테이먼트 시스템에는 관심없는 사람들에게는 그것이 설사 강력하다 하더라도 워크맨만 못한법입니다.

:D

하지만 "그 강력하다던 홈 엔터테인먼트 시스템이 워크맨만도 못하더라. 홈 엔터테인먼트 시스템은 워크맨을 따라갈려면 아직 멀었다." 라고 얘기하는것은 올바른 발언은 아니죠. :-)

hys545의 이미지

rekcuf wrote:
예전 어떤 분의 말씀처럼 문파(?)간의 충돌은 의미가 없지요.
150여 개(맞나요?)나 되는 배포판들의 다양성은 각각마다 특징과 장단점이 있으니 자기에게 맞는 것을 고르면 되는 것 뿐이지요.

rpm 방식의 패키지 관리는 모든 분들이 인정하듯이 apt-get을 쉽게 쓸 수 있는 데비안 계열에 비하면 불편한 것은 사실입니다. 저도 아직 초보이긴 하지만 의존성의 짜증때문에 데비안 계열로 넘어왔고요... 하지만 rpm 방식이래도 RHN과 같이 중앙에서 유지 관리해 준다면 전혀 불편하지 않죠.
단, 서비스에는 공짜가 없으므로 돈을 지불해야 하니 개인들에게는 먼 얘기고요.
(한소프트는 아직 평가판에도 보안 업데이트를 해 주던 것 같습니다).

이글의 원 제목은

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

인데, 덧글들이 좀 다른 방향으로 간 것 같네요.
한소프트 리눅스의 서버버전 얘기이긴 하지만, 데스크탑버전쪽으로도 지속적인 발전이 계속 있어서, 저같이 맨 처음 접하는 리눅스가 한소프트리눅스인 사람들이 많아졌으면 좋겠습니다.
사실 윈도우에서 데비안같은 배포판으로 바로 넘어오는 것은 거의 불가능하지 않나요? 그런 면에서는 한소프트리눅스에 정말 최고의 존재의 의미가 있지 않을까요!!!

redhat도 수동으로 업데이트하면 됩니다.
보안업데이트한 것도 GPL을 따르기 때문에 다운로드 못하게하면 문제가 생기기 떼문에
최소힌 ftp로 다운가능하게 합니다.

즐린

다크슈테펜의 이미지

ydhoney wrote:
다크슈테펜 wrote:

Quote:

강력한 홈엔터테이먼트 시스템이라도 그냥 평소에 워크맨이나 만지작거리고 홈엔터테이먼트 시스템에는 관심없는 사람들에게는 그것이 설사 강력하다 하더라도 워크맨만 못한법입니다.

:D

하지만 "그 강력하다던 홈 엔터테인먼트 시스템이 워크맨만도 못하더라. 홈 엔터테인먼트 시스템은 워크맨을 따라갈려면 아직 멀었다." 라고 얘기하는것은 올바른 발언은 아니죠. :-)


그에 대해서는 제가 실언을 한것 같습니다.하지만 제가 홈엔터테이먼트 워크맨 예를 든것은 기능이 강력하다고 하더라도 사용하기가 용이하냐에 기인한것입니다.물론 YUM도 구이툴이 있고 사용하기 쉬운 방법도 있을지도 모릅니다.하지만 리파지토리 수적으로나 그리고 리파지토리 사용방법에 대해서는 그렇게 심플 하다고는 하실수는 없을 것 같습니다만.초보들에게 MPlayer설치에 대해서 간단히 이야기 해주고 설치하라고 한다면 YUM이 빠를까요 아니면 apt-get이 간단할까요...? 물론 시스템에 Mplayer가 설치되어 있지 않은 상태에서 물론 리파지토리도 역시 설정되어 있지 않은 상태를 말합니다.그리고 어느쪽에 대해서 더 쉽게 설명해줄수 있을까요..YUM을 통한 MPplayer설치가 더 설명이 쉬울까요 아니면 apt-get을 통한 Mplayer설치가 더 설명이 쉬울까요

인생이란게 다 그런게 아니겠어요....? 뭘(?)
http://schutepen.egloos.com

ydhoney의 이미지

다크슈테펜 wrote:
ydhoney wrote:
다크슈테펜 wrote:

Quote:

강력한 홈엔터테이먼트 시스템이라도 그냥 평소에 워크맨이나 만지작거리고 홈엔터테이먼트 시스템에는 관심없는 사람들에게는 그것이 설사 강력하다 하더라도 워크맨만 못한법입니다.

:D

하지만 "그 강력하다던 홈 엔터테인먼트 시스템이 워크맨만도 못하더라. 홈 엔터테인먼트 시스템은 워크맨을 따라갈려면 아직 멀었다." 라고 얘기하는것은 올바른 발언은 아니죠. :-)


그에 대해서는 제가 실언을 한것 같습니다.하지만 제가 홈엔터테이먼트 워크맨 예를 든것은 기능이 강력하다고 하더라도 사용하기가 용이하냐에 기인한것입니다.물론 YUM도 구이툴이 있고 사용하기 쉬운 방법도 있을지도 모릅니다.하지만 리파지토리 수적으로나 그리고 리파지토리 사용방법에 대해서는 그렇게 심플 하다고는 하실수는 없을 것 같습니다만.초보들에게 MPlayer설치에 대해서 간단히 이야기 해주고 설치하라고 한다면 YUM이 빠를까요 아니면 apt-get이 간단할까요...? 물론 시스템에 Mplayer가 설치되어 있지 않은 상태에서 물론 리파지토리도 역시 설정되어 있지 않은 상태를 말합니다.

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

p.s

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

다크슈테펜의 이미지

:D
이제 RPM하고 KDE에 관해서는 우선 잠그는게 좋을 것 같습니다.뭐 YUM쪽이 더 편하신분들도 있고 apt-get이 더 편하신 분들도 있으시고 하니 저야 데비안쪽이 더 편해서 그렇게 말씀 드린거니 용서를 바랍니다.

PS:
YUM은 간단해야 하고 apt-get은 빨라야 합니다.후다닥~~~

인생이란게 다 그런게 아니겠어요....? 뭘(?)
http://schutepen.egloos.com

바라미의 이미지

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

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

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

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

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

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

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

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

myohan의 이미지

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

emerge 만세 !!!

젠투 만세 !!! 8)

---------------------------------------
blog : http://myohan.egloos.com

코너리의 이미지

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

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

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

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

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

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

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

The difficulty in life is the choice.

notnull의 이미지

항상 한쪽에 치우친 의견이 나올때마다 그냥 보고만 있기가 뭐해서 그동안 생각했던 말을 올렸던것이 문제가 됐군요.

apt-get 이 yum 에 비해서 빠르고 안정적인것은 저도 개인적으로 인정하는 부분이지만 업데이트가 잘되고 설치가 잘 된다고 사용하기 편하다는건 기술자적 입장에서의 문제이지 엔드유저의 입장에서 편한것과는 또 다른 문제일것입니다.

OS 를 개발하는 업체 입장에서 만약 데비안 시스템이 개발하기 편했다면 대부분의 상용 리눅스는 데비안 기반이어야 할 것입니다.

그러나 현실은 거의 90% 의 상용 리눅스 OS 는 RPM 기반이라는 것이죠. 그건 무시할 수 없습니다. 윈도우즈 사용자가 훨씬 많은 이유는 윈도우가 어찌되었건(어찌되었건이란 먼저 알게 되었기 때문에 편하게 느껴질 뿐이라 하더라도) 편하기 때문입니다.

마찬가지로 RPM 이 설치시에 의존성 때문에 짜증난다고 생각하지만 그렇다고 해서 사용하는데 있어 (설치부분을 제외한) 다른 부분이 짜증나는건 아니지 않겠습니까.

Fedora 의 인터페이스가 다른 안정성 있는 리눅스 OS 에 비하여 좀 더 엔드유저에게 가깝게 빨리 다가가고 있는것은 무시할 수 없는 사실입니다.
물론 최근엔 우분투가 앞서거니 뒤서거니 하면서 편리함을 추구하고 있지요.

제가 말하고자 했던 요지는 그런게 아니었습니다. 물론 취향입니다. 리눅스를 신봉할 수도 있고 그냥 내가 사용하는 단순한 OS 의 하나로 편하게 생각하는것도 취향입니다.

데비안을 좋아하시는 분들께서 데비안을 좋아하는것이 자신의 취향이듯 레드햇계열을 좋아하는 사람들의 취향을 초보라서 그렇다, 그거는 뭐가 나쁘다더라 라는 식의 말은 삼가해주셨으면 좋겠다는 겁니다. 레드햇 계열을 좋아하는것도 그 사람들의 취향이니까요.

가끔보면 레드햇관련 얘기가 나오면 무조건 하고 데비안이 좋은데 왜 레드햇을 쓰냐고 묻는 분들이 있어서 하는 얘기입니다.

권유하는건 재미있습니다. 그러나 권유하기전 올바른 정보가 아닌 초보자로 하여금 객관적인 판단을 흐리게 만드는 코멘트등은 문제가 된다고 보는겁니다.

저도 그냥 권유를 하고 싶었을 뿐입니다. 제 실수로 글의 모양새가 싸움을 거는 형상이 되어버렸을지도 모르겠습니다. (그러나 이 글만 읽고 실제로 제가 잘못 글을 올렸구만.. 이라고 생각진 말아주십시오.)

이젠 (처음 리눅스를 알기 시작한 사람들을 제외하고서) 좀 써본 사람들이라면 RPM 이 좋다, DEB 가 좋다는 식은 삼성 TV 가 최고다 LG TV 가 최고다 라는 경쟁만큼 허무한 것이라는 생각입니다.

다크슈테펜의 이미지

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

인생이란게 다 그런게 아니겠어요....? 뭘(?)
http://schutepen.egloos.com

버려진의 이미지

국내 배포판이 RPM을 계속 밀고 나가려면

많은 패키지를 제공해주는게 필요하겠죠.

아니면 페도라용 등을 문제없이 가져다 쓸 수 있다던지..

yum이나 이런게 편하고 어쩌고를 떠나서 원하는 패키지가 없으면 말짱 꽝이니까요.

(저번에 xchm이 없어서 밀어버렸던 아픔이 아직도..)

fibonacci의 이미지

notnull wrote:

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

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

No Pain, No Gain.

mrjh76의 이미지

fibonacci wrote:

레드햇 쓰다가 거의 2년 전쯤 데비안으로 옮겼습니다. 왜 옮겼느냐..
당시에 xfig를 깔려고 했는데 libc6 신버전을 요구했습니다.
그런데 libc6 신버전을 깔려고 하다 보니 일단 지워야 하는데, libc6 구버전에 의존된 패키지가 하나 둘이 아니더군요.
의존성 있는 패키지 다 지우고 libc6신버전 깔고 xfig 깔고...
일련의 작업들이 당시 레드햇에서는 간편하지 않았었죠.

한동안 패키징을 해보았던,,, 경험으로,,, 간단히 하나만 이야기 할께요!

RPM 패키지의 의존성에러는 상당히 좋은 기능입니다!~
윗분의 예처럼... 특정 패키지를 삭제하려고 하는데...
의존성 에러를 보이며,,, 삭제가 되지 않는것은,,, 어떤 특정 패키지에서 삭제하려는 패키지를 사용하고 있다는것을 알려주는것입니다!

또한 신규 패키지를 설치하는데,,, 특정 패키지가 필요하다고 의존성 에러는 보여주는것 또한 설치하려는 패키지의 온전한 기능을 모두 사용하기 위해 알려주는것이고요...

위와 같이... 이미 특정 환경에 맞춰 컴파일된 바이너리를 사용하는 입장에서는 RPM이건... 다른 패키지 방식이건... 어찌할수 없는 부분이 아닌가요?

윗분이 경험한... 문제는 RPM의 문제가 아니라... 레드헷이... 각각의 패키지를 너무 유기적으로 잘 조합해 놓아서 그런것 아닐까요?

언제 시간나면... 데비안이랑... 젠투랑 한번 써봐야겠네요!!!

전 지금껏... RPM 기반의 배포판만 써봐서.... 다른 환경은 잘 모르겠네요!!!

notnull의 이미지

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

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

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

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

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

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

Quote:
이 과정에서는 비교는 필연적이라고 생각합니다

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

surie의 이미지

너무 무겁다는....
설치 시 간단히 2기가 넘어버리는...
gnome 도 없고 개발, 서버 패키지도 뺏는데
간단하게 2기가 넘다니...
옛날 한컴3.1의 슬림함...
제발 패키지 개별선택이 좀 가능했으면...
패키지는 많은데 선택의 폭이 좁다보니 원...

다크슈테펜의 이미지

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

인생이란게 다 그런게 아니겠어요....? 뭘(?)
http://schutepen.egloos.com

정태영의 이미지

다크슈테펜 wrote:
소비자의 선택을 위해서 RPM 레드햇 수세용 맨드리바 용 걸어 놨다고 한다면 어느것을 선택하실껀가요 레드햇이면 레드햇용만 설치할 것이고 수세용이나 맨드리바용은 설치될수도 있겠지만 설치가 안될수도 있습니다.이런것을 소비자 선택이라고 할수 있는 건가요...?

deb 기반으로 패키징을 한 배포판이 적을 뿐입니다... dpkg 를 사용해서 패키징을 한 배포판이 많아지게 되면 똑같은 문제가 발생합니다...

그건 rpm 을 사용하느냐 아니면 deb를 사용하느냐가 문제가 아니란 겁니다... deb 로 설치판을 만들어놓았다고 데비안을 지원하는게 아닐 수도 있습니다... 뭔가 잘못 생각하고 계신듯 싶군요...

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

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

다크슈테펜의 이미지

정태영 wrote:
다크슈테펜 wrote:
소비자의 선택을 위해서 RPM 레드햇 수세용 맨드리바 용 걸어 놨다고 한다면 어느것을 선택하실껀가요 레드햇이면 레드햇용만 설치할 것이고 수세용이나 맨드리바용은 설치될수도 있겠지만 설치가 안될수도 있습니다.이런것을 소비자 선택이라고 할수 있는 건가요...?

deb 기반으로 패키징을 한 배포판이 적을 뿐입니다... dpkg 를 사용해서 패키징을 한 배포판이 많아지게 되면 똑같은 문제가 발생합니다...

그건 rpm 을 사용하느냐 아니면 deb를 사용하느냐가 문제가 아니란 겁니다... deb 로 설치판을 만들어놓았다고 데비안을 지원하는게 아닐 수도 있습니다... 뭔가 잘못 생각하고 계신듯 싶군요...


그래서 패키징 방법이 통합되어야 한다는 겁니다.그게 RPM이던 DEB던 간에 지금은 RPM이라도 이름이나 뚜껑을 열기전에는 어느 배포판용인지 알수 없으며 그거는 DEB도 마찬가지 입니다.그래서 서로 비교를 하면서 보완할것은 보안하고 그리고 개선할것은 개선하면서 새로운 패키징 방법을 만들던지 아니면 기존 패키징에서 보안하는 형태로 나가던지 해서 모든 리눅스에서 적용되는 패키징 방법을 찾자고 생각하는 겁니다.이과정에서 DEB의 패키지 관리 방식과 RPM 패키지 관리 방식 그리고 젠투의 패키지 관리 방식이 비교 되어야 되는 것은 당연한거 아닌가요...?
위에 RPM은 그저 예일 뿐입니다.그것은 DEB도 마찬가지입니다.
이게 패키지나 패키지 관리 방식에 비교는 무의미하다는 것에 대한 진정한 반론이 될것 같습니다.

인생이란게 다 그런게 아니겠어요....? 뭘(?)
http://schutepen.egloos.com

mrjh76의 이미지

다크슈테펜 wrote:

그래서 패키징 방법이 통합되어야 한다는 겁니다.그게 RPM이던 DEB던 간에 지금은 RPM이라도 이름이나 뚜껑을 열기전에는 어느 배포판용인지 알수 없으며 그거는 DEB도 마찬가지 입니다.그래서 서로 비교를 하면서 보완할것은 보안하고 그리고 개선할것은 개선하면서 새로운 패키징 방법을 만들던지 아니면 기존 패키징에서 보안하는 형태로 나가던지 해서 모든 리눅스에서 적용되는 패키징 방법을 찾자고 생각하는 겁니다.이과정에서 DEB의 패키지 관리 방식과 RPM 패키지 관리 방식 그리고 젠투의 패키지 관리 방식이 비교 되어야 되는 것은 당연한거 아닌가요...?
위에 RPM은 그저 예일 뿐입니다.그것은 DEB도 마찬가지입니다.

패키지 방법이 통합되면, 통합되면... 이런 일련의 문제들이 해결될 수 있을까요?
지금까지... 다크슈테펜님의 생각과 같은 맥락에서... 이미 여러가지 일들이 수행되어왔습니다.
리눅스 표준 단체도 있고... 각각의 배포판을 통합하겠다고... 나섰던 업체들도 있었고...
우리나라에서는 부여(?) 뭐... 이런것도 있었고....
아시아 눅스도 이런 일련의 문제를 해결하겠다고... 나왔다고 보면 되겠죠...

하여간에.... 여러가지 시도들이 있었습니다!!!

하지만,,, 서로의 이해관계로... 지금과 같은 상황입니다!

이런 상황을 타계하기 위한 좋은 방법은??? 무엇일까요???

가장 큰 리눅스 배포판 회사가... 리눅스 시장을 통일하여... 독점을 하면 되겠네요!!!

다크슈테펜의 이미지

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

인생이란게 다 그런게 아니겠어요....? 뭘(?)
http://schutepen.egloos.com

hys545의 이미지

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

윈도우에서 패키지방식이하면 msi같은건데
이건 98에서도 가능합니다.

즐린

ddoman의 이미지

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

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

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

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

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

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

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

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

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

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

다크슈테펜의 이미지

내가 졌소 GG

인생이란게 다 그런게 아니겠어요....? 뭘(?)
http://schutepen.egloos.com

mrjh76의 이미지

다크슈테펜 wrote:
내가 졌소 GG

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

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

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

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

tinywolf의 이미지

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

emerge 만세 !!!

젠투 만세 !!! 8)

젠투 만만세!!

젠투 2005.1이닷 꺄앗 만쉐이~

ㅡ_ㅡ;

mrjh76의 이미지

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

emerge 만세 !!!

젠투 만세 !!! 8)

젠투 만만세!!

젠투 2005.1이닷 꺄앗 만쉐이~

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

bokkwonsu의 이미지

전 그놈보다는 KDE가 더 친숙하고 편하던데요 ㅎㅎ

아직 리눅스 입문자라

경험해본 리눅스가 레드헷계열이라

RPM이나 KDE가 편하게 보이나 봅니다

vacancy의 이미지

mrjh wrote:
fibonacci wrote:

레드햇 쓰다가 거의 2년 전쯤 데비안으로 옮겼습니다. 왜 옮겼느냐..
당시에 xfig를 깔려고 했는데 libc6 신버전을 요구했습니다.
그런데 libc6 신버전을 깔려고 하다 보니 일단 지워야 하는데, libc6 구버전에 의존된 패키지가 하나 둘이 아니더군요.
의존성 있는 패키지 다 지우고 libc6신버전 깔고 xfig 깔고...
일련의 작업들이 당시 레드햇에서는 간편하지 않았었죠.

한동안 패키징을 해보았던,,, 경험으로,,, 간단히 하나만 이야기 할께요!

RPM 패키지의 의존성에러는 상당히 좋은 기능입니다!~
윗분의 예처럼... 특정 패키지를 삭제하려고 하는데...
의존성 에러를 보이며,,, 삭제가 되지 않는것은,,, 어떤 특정 패키지에서 삭제하려는 패키지를 사용하고 있다는것을 알려주는것입니다!

또한 신규 패키지를 설치하는데,,, 특정 패키지가 필요하다고 의존성 에러는 보여주는것 또한 설치하려는 패키지의 온전한 기능을 모두 사용하기 위해 알려주는것이고요...

위와 같이... 이미 특정 환경에 맞춰 컴파일된 바이너리를 사용하는 입장에서는 RPM이건... 다른 패키지 방식이건... 어찌할수 없는 부분이 아닌가요?

윗분이 경험한... 문제는 RPM의 문제가 아니라... 레드헷이... 각각의 패키지를 너무 유기적으로 잘 조합해 놓아서 그런것 아닐까요?

언제 시간나면... 데비안이랑... 젠투랑 한번 써봐야겠네요!!!

전 지금껏... RPM 기반의 배포판만 써봐서.... 다른 환경은 잘 모르겠네요!!!

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

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

hiseob의 이미지

fedora 나오기전만해도 glibc 업데이트 하다가 커널패닉나고 패키지깨지고 결국 밀어버리는일이 잦았습니다.

hys545의 이미지

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

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

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

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

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

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

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

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

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

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


MS에서 관리하는 패키지들이 대부분입니다.그래서 의존성 문제를 들 겪는거겠죠.
윈도우도 의존성 문제 심각합니다
특히 mfc이거 개발할떼 버젼하고 시스템에 깔린 버젼이 다르면 에러 발생할수도 있습니다.
그래서 대부분의 풀그림은 설치할때 풄그림 깔린데다거 mfcxx.dll도 같이 복사해놓습니다.

즐린

^_^의 이미지

RHN(Red Hat Network)만만세!!!!!!

----------------------------------------------------------------------
웃는 얼굴 헤죽 헤죽

doodoo의 이미지

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

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

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

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

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

aNsITAte의 이미지

자기가 쓰던거 쓰는게 최고가 아닐지;;;

저같은 경우에는 처음 사용할대부터 데비안을 썼는데...

나중에 레드햇이나 젠투 어떤걸 설치해봐도 오래안가서

지우게 되더라구요.

결국엔 자기가 쓰던게 최고입니다. ㅡ.ㅡa

그립다는 것은 아직도 네가 내 안에 남아 있다는 뜻이다.
그립다는 것은 지금은 너를 볼 수 없다는 뜻이다.
볼 수는 없지만 보이지 않는 내 안 어느 곳에 네가 남아 있다는 뜻이다.
-이정하의 《혼자 사랑한다는 것은》중에서-

mate의 이미지

저는 윈도우즈 즐기는 사람인데요...
근데 요즘 라뉵스에서 돌아가는 voIP pabx 시스템등 저비용 시스템을 찾다가 리뉵스에 기웃거리는 이방인입니다.
오늘 아시아리뉵스 다운로드 받고서 asp.net을 한번 시도해볼려고 하는데 혹시 해보신분 계시나요? 그리고 한글판 웹서버나 영문판 웹서버나 한글 컨텐츠 있는 static 웹페이지나 dynamic web page난 관계없죠?

제목과 나의 댓글이 연관이 있을듯하면서 좀 사이드로 가네요.

마잇의 이미지

asp.net은 IIS 에서만 가능한 걸로 알고 있습니다. 윈도우즈 이외의 환경에서 돌아가는 IIS는 없지요 아마.
--
마잇


--
마잇