리눅스 배포판들, 이래서 아쉽다?

배포판끼리 설정위치라던지 방법등이 다른거가 제일 큰 문제라고 생각하며, 여전히 /bin, /sbin /usr/bin, /usr/local/bin, /usr/sbin 등이 통일 안된것도 문제 같습니다.

아래부터는 FC3 를 쓰면서 느끼는 점입니다. 설치시의 yum repo 를 그대로 쓰고 있습니다.

노트북 무선랜을 기본적으로 안 잡아줍디다;; 노트북의 터치패드 설정을 하는 프로그램이 없습니다(못 찾은건가요;;)

yum gui 가 없는것은 통탄할만한 일이며 특히 yum search 좀 그렇습니다. debian 의 aptitude 가 너무 생각납니다.

기본적으로 ntfs 를 read only 라도 마운트 할 수 있으면 좋겠습니다(Xandros 는 되더군요)

java VM 이 yum 안에 없다는게 자바에 관심있는 저에게 좀 아쉬우며, eclipse 도 덩달아 없습니다;;

(참고로 yum 쓴 이후부터 외부(?) 에서 받은 rpm 은 설치하기 싫어서리;;)

볼드 패치 안되어 있는거랑

윈도우키를 이용한 단축키 조합을 만들어내지 못하는것도 아쉽습니다.

그놈 패널에 아이콘이 자동정렬이 없는것도(삭제시에 위치가 자동으로 당겨졌으면 좋겠더군요 - 윈도우의 QuickLaunch 처럼)

그리고 그놈을 쓰는데 KDE 나 윈도우xp 처럼 최근 이용한 프로그램이 없어서...

글꼴이 안 뭉개졌으면 좋겠습니다.

그래픽카드를 제대로 못 잡아줬는지 BzFlag 인가.. 3D 탱크게임을 하는데 힘듭니다. 라데온9600

아.... 더이상은 생각 안나는 군요. 속시원합니다. ^^;;;

주제와 벗어나지만, 저는 페도라 1에서 2는 apt-get으로, 2에서 3는 yum으로 업데이트해서 쓰고 있습니다. 정확히 말하면, 1->1.92->2->3t2->3 이런식으로 테스트2가 나온 시점에서 중간 업그레이드를 했었죠. 몇건의 문제는 있었지만 재설치를 요하는 경우는 없었습니다. 그리고, 현재 쓰고 있는 시스템이 불안정하다고는 생각치 않습니다. 주당 최소 50시간 이상을 쓰는 데탑이니까요. 또한 매번 버전업 후 성능이 향상되었다고 느낍니다.

RPM이 제일 불만입니다. ^^;

yum은 토종 배포판에서만 써봤기 때문에 딱히 할말은 없구요.

레드햇이나 페도라를 쓰는 사람을 보면 이상하게 쳐다볼 정도입니다. ( -.ㅡ)? (위험한 발언)

atie 님 현재 fedora 2 를 쓰고 있는데, fedora 3 로 업그레이드를 할까 말까 고민중에 있습니다.

업그레이드시에(yum 이용) 주의할 점이 있다면 어떤것이 있을까요?

fedora 1 에서 2 로 업그레이드 할때는 별이상이 없었던 것 같은데, 혹시 몰라서요.^^

RedHat, Suse, Mandrake 를 만져본 (전부 RPM 베이스군요 ^_^) 입장에서는...

"APM 빼고 다 있는 패키지 없나" 싶군요.

APM 이 요구하는 라이브러리가 좀 있고 특히 PHP 같은 경우 상당히 많아서 소스컴파일 땡기고 상황에 따라 Zend Optimizer 랑 mmCache 까는데 이것들이 기본으로 깔린 배포판은 그 어플리케이션의 기본 설치위치와 달라서 오히려 불편한 경우가 종종 있습니다.

그것보다는 설치 패키지의 개념이 리눅스에서는 모두 의존성이라는 처음 접하는 사람에게는 생소한 개념을 공통적으로 갖고 있다는 점이 문제인 듯 싶습니다. 사실은 이것은 리눅스 배포본들의 장점입니다만 의존성이 복잡하게 꼬이기 시작하면 이것 역시 사용자의 입장에서는 해결하기가 쉽지 않은 문제이지요.

이 문제는 드라이버의 소스코드 공개 여부와 관련이 있습니다. 많은 경우 개발사의 입장에서는 드라이버 소스 코드를 비공개로 하고 싶어합니다. 경쟁사에게 기업비밀을 노출시키지 않고 싶기 때문입니다. 리눅스 오에스 자체가 오픈 소스, 특히 GPL이기 때문에 이런 문제가 생깁니다. 상당히 해결하기 어려운 문제중의 하나입니다.

이것 역시도 자바가 상용이라는 점과 미묘하게 연관이 되어 있습니다. 페도라의 경우 패키지 선정에 어떤 정책을 쓰는지 잘 모르겠습니다만 썬의 자바는 여전히 상용 패키지인 까닭에 기본으로 배포본에 넣어서 패키지를 배포하는 데 미묘한 문제가 있을 겁니다. 데비안의 경우는 썬의 자바 라이센스가 오픈소스 라이센스의 기준에 미달하기 때문에 자바를 배포본에 포함하지 않고 있을 겁니다.

이런 부분은 한번 Gnome 개발팀에 버그 리포팅이나 기능 개선쪽으로 제안을 해 보시는 것도 괜찮으리라고 봅니다. 이것이 오픈 소스의 장점 중의 하나이기도 하구요.

bzflag는 좀 귀찮더라도 설정을 잘 잡아주시고 (요즘도 x.org 에서 3d 가속 설정에 dri 모듈을 쓰는지는 잘 모르겠습니다만...) 플레이 해 보시길 권합니다. 무척 재밌는 게임이라서요.

전체적으로 배포본과 관련된 불편함들은 리눅스 외적인 부분에서 파생되는 문제들이 대부분입니다. 특히 소프트웨어 특허나 기업비밀과 같은 부분을 오픈소스에서 어떻게 처리할 것인가 하는 문제는 여전히 머리아픈 문제로 남아있고, 오픈 소스 진영에서도 유럽에서만큼은 소프트웨어 특허는 인정하지 않는 쪽으로 청원을 넣는 정도 밖에 솔루션을 못 내놓고 있습니다. 소프트웨어 특허가 속편히 인정되지 않는쪽으로 나가더라도 기업비밀을 오픈소스에서 어떻게 지켜줄 것인가는 여전히 쉽지 않은 문제로 남을 수 밖에 없습니다.

궁금한 게 있는데.. 아쉬비 하다는 게 무슨 뜻입니까 ?

아쉽다.. 라고 하는 걸 "아쉬비~" 라고 가볍게 적습니다. 평소 말로도 하는 말이기도 하고요;

활용례..는 검색을 ㅎㅎㅎ

우리나라 배포판은 제대로 활성화된 커뮤니티가
아닌상태라 너무 아쉽다는.

페도라 프로젝트가 유독 부럽네요.

main portage tree 에 반영이 되지 않았더라도..
local machine 에서는.. PORTAGE OVERAY DIR을 통해..
간단히.. 자신만의 ebuild 를 유지할 수 있으며..

없는 패키지가 아니라.. 새버젼에 대한 ebuild 가 아직 안나온 경운..
ebuild 파일의 이름을 바꿔주고..

ebuild foo-version.ebuild digest
emerge foo

만으로도 대부분의 경우 정상적으로 동작합니다..

그리고 말씀하신대로 대부분의 툴들은..

./configure
make
make install

의 과정을 통해 인스톨이 되며.. 그렇기 때문에.. eutils 라는 eclass 를 inherit 하는 것과.. 소스의 위치와 설명을 명시한 것 만으로도..

ebuild 를 만들 수 있습니다.. 노가다라기 보다 직접 컴파일하는 것 만큼 쉽다라는 얘기죠 :)

위의 ebuild 에서 HOMEPAGE와 SRC_URI 를 고쳐주시는 것만으로도..
정상적으로 동작합니다 :)

마지막으로 설치하시려는 것에.. 대한 정확한 이해 없이.. 직접 빌드하셔서 쓰는 것보다는.. 그래도 좀 더 많은 사람들이 신경써서 설정해놓은 ebuild 를 쓰시는 걸.. 더추천해드리고 싶군요..

앞에 wwl 님께서

그리고... 어떤 배포판은 /sbin 이 존재하고 어떤 배포판은 /usr/sbin 에 존재하고 이런것들 말하는 거죠.

알고 보면 RPM 만큼 편한 것도 없습니다. 패키지의 의존성에 대한 이해가 부족한 경우 많이 나오는 얘기일 것 같습니다. ;-)

어떻게 보면 그만큼 RPM 사용법이 편하고 보편화 되어 있기 때문에 이런 제기가 많이 나올 수도 있겠군요. ^^; RPM 자체로는 의존성 처리에 한계가 있습니다만, 요즘은 rhdb 와 yum 등의 user interface 를 이용하면 거의 해결되는 분위기 입니다.

라이브러리 때문에 윈도우처럼 쉽게 깔지는 못할 것 같습니다.

deb 를 레드햇에서 바라는것도 욕심인듯 하고.

최선의 선택은 역시 tar.gz or tar.bz2 일텐데 -.- 시간도 문제일테고

암튼 쉬운문제는 아닐꺼 같네요 :(

인스톨쉴드라...
레댓에서 rpm더블 클릭했더니 비슷한거 나오든데. 그 정도면 충분하지 않나요? ㅋ

저도 rpm에 물려서 젠투, FreeBSD로 선회해서리.

배포판에 대한 불만이라기 보다 그냥 개인적인 바램인데..
왜 qt를 이용한 입력기는 없는지..
나비하나 때문에 gtk시리즈를 줄줄히 까는 거 싫어용.. ㅠ,.ㅠ
(하갸 GIMP도 많이쓰니 안깔수는 없다만. ㅡ,.ㅡ;;;)
주로 KDE를 쓰기 땀애 걍 불만이네용. ㅋ