벤치마크 결과가 어떤지 모르겠으나, X 윈도우가 MS윈도우보다 느리게 느껴지지 않고 성능 역시 뒤떨어진다고 생각되지 않습니다.
윈도는 다이렉트 렌더링 방식입니다. Win32 API 호출을 하면 윈도 GDI가 화면에 바로 뭔가를 그리죠. 반면 X는 클라이언트-서버 방식입니다. Xlib 호출을 하면 이게 X 프로토콜로 가공이 된 후 X 서버로 보내지고 X 서버는 다시 받은 X 프로토콜을 해석해서 화면에 뭔가를 그리게 됩니다. 당연히 X의 방식이 훨씬 느릴 수 밖에 없습니다. 느리게 느껴지지 않는다면 여러분의 CPU 파워가 강력하거나, 동시에 띄운 작업수가 많지 않아서 일 겁니다.
이 문제와 관련해서 최근 XFree86 프로젝트의 설립자중 한명인 David Wexelblat조차도 다음과 같이 이야기했습니다.
Quote:
(X와 같은) 클라이언트-서버 디스플레이 시스템은 실제 컴퓨터 사용자 대부분과는 엄청나게 무관하다. X는 다이렉트 렌더 모델로 대체되어야 한다.
...client-server display systems are utterly irrelvent to the majority of real-world computer users. X needs to be replaced by a direct-rendered model, ...
그밖에 UNIX Hater's Handbook "X 윈도우즈의 재앙" 부분을 읽어 보시면 X의 단점이 적나라(?)하게 기술되어 있으니 참고가 될 듯합니다.
X윈도우는 MS 제품 보다 훨
느립미다..
사양이 올라가면 당연 빨라 져야지만..
하드웨어에 따라서는 별반 성능 향상이 없는 경우도
있습니다..
제컴퓨터.. 펜티엄 3 500Hz 190M 의 속도와..
펜티엄 4 2GHz 의 속도차가 많이 나지 않터군요..
둘다 프로그램 뜨는걸 기다려야 하니.. 원~~~ _-_
꼭 자바 같다는 생각이 들더군요..
게임쪽 상태는 더 안좋아지는것 같습미다..
벤치마크 결과가 어떤지 모르겠으나, X 윈도우가 MS윈도우보다 느리게 느껴지지 않고 성능 역시 뒤떨어진다고 생각되지 않습니다.
윈도는 다이렉트 렌더링 방식입니다. Win32 API 호출을 하면 윈도 GDI가 화면에 바로 뭔가를 그리죠. 반면 X는 클라이언트-서버 방식입니다. Xlib 호출을 하면 이게 X 프로토콜로 가공이 된 후 X 서버로 보내지고 X 서버는 다시 받은 X 프로토콜을 해석해서 화면에 뭔가를 그리게 됩니다. 당연히 X의 방식이 훨씬 느릴 수 밖에 없습니다. 느리게 느껴지지 않는다면 여러분의 CPU 파워가 강력하거나, 동시에 띄운 작업수가 많지 않아서 일 겁니다.
이 문제와 관련해서 최근 XFree86 프로젝트의 설립자중 한명인 David Wexelblat조차도 다음과 같이 이야기했습니다.
Quote:
(X와 같은) 클라이언트-서버 디스플레이 시스템은 실제 컴퓨터 사용자 대부분과는 엄청나게 무관하다. X는 다이렉트 렌더 모델로 대체되어야 한다.
...client-server display systems are utterly irrelvent to the majority of real-world computer users. X needs to be replaced by a direct-rendered model, ...
그밖에 UNIX Hater's Handbook "X 윈도우즈의 재앙" 부분을 읽어 보시면 X의 단점이 적나라(?)하게 기술되어 있으니 참고가 될 듯합니다.
그런데 왜 제 컴퓨터에서는 Quake3, Unreal Tournament,
Return to Castle Wolfenstein등의 게임은 리눅스에서 더 좋은 성능을
보일까요?
제가 보기엔 각 응용 프로그램에 따라서 다른 것 같습니다. 이건 드라이버나
이런 것들의 질에 더 많은 영향을 받는 것 같습니다. X 프로토콜의 구조라기
보다는...
이젠 그런 자잘한 속도 논쟁보다는 얼마나 편하고 쓸만하느냐에 중점을 둬야 하지 않나 싶네요.
어차피 지금의 하드웨어 발전 속도라면야 조만간 그정도 속도야 충분히 뒤집고도 남습니다.
지금은 약간 비디오 렌더링 속도가 차이가 있긴 하지만.. 윈도처럼 직접 쓰나 뭐 중간에 잠시 거치나.. 씨퓨 속도가 3기가에 비디오 카드가 요즘 하이엔드급쯤 되도 유저가 그 속도차를 느낄수나 있을지요.
지금도 사실 왠만하면 그차이를 느끼는 사람은 드뭅니다. 그걸 따지고 드는 전문 개발자가 아닌한.. 안그런가요
여지껏 전 한번도 못느꼈습니다.
저도 그렇게 생각합니다. 이미 윈도우즈나 리눅스에서는 모질라가 느리다는 얘기가 거의 언급되지 않고 있는지 오래입니다. 그런데 시피유가 상대적으로 느린 매킨토시로 가면 다들 모질라가 느리다고 생각합니다.
엑스 윈도우 자체의 설계가 문제가 있다고는 하지만.... 이걸 버리고 새 플랫폼을 채택해야할만큼 나쁜 플랫폼인 것 같지는 않습니다.
오히려 최근의 리눅스 커뮤너티의 활동을 지켜보다보면 리눅스에서 엑스의 문제는 엑스 자체의 문제보다는 XFree86의 문제가 크지 않나 싶은데 다른 분들은 어떻게 생각하시는지요? Keith Packard가 프로젝트 forking까지 들고 나오면서 이 문제를 걸고 넘어진 것은 바람직한 일이라고 봅니다. 사실 지금도 리눅스를 까는데 걸리는 문제중의 하나가 XFree86에서 비디오 카드 셋업입니다. 리눅스의 역사가 이제 상당히 오래되어가고 있는데도 불구하고 이쪽이 아직까지 병목현상으로 작용하는 이유를 잘 모르겠습니다...
"I conduct to live,
I live to compose."
--- Gustav Mahler
MS 윈도우즈에서는 OpenGL을 직접처리하지 않고, Direct3D로 변형하여 처리합니다.리눅스는 그렇지 않죠. 그래서 더 빠른 것입니다.
이런 말은 처음 들었습니다. Windows 안에서의 OpenGL과 Direct3D의 작동
방식은 전혀 다릅니다. 위에 내열된 게임은 대부분 OpenGL로 구현되었으므로
Windows에서도 각 VGA 카드 드라이버 안의 OpenGL 드라이버에 의해 OpenGL 파이프라인을 따라서 작동 됩니다.
그리고 X 윈도우 시스템도 시대에 맞게 변화할 때가 되지 않았나 생각합니다.
유닉스,리눅스에서의 윈도우 시스템은 거의 XFree86의 독주였습니다.
이 부분에는 왜 다양성이 존재 하지 않는 것인지 모르겠습니다. 너무 큰
작업이라 그런지, 아니면 제가 모르고 있는것인지.
이젠 그런 자잘한 속도 논쟁보다는 얼마나 편하고 쓸만하느냐에 중점을 둬야 하지 않나 싶네요.
어차피 지금의 하드웨어 발전 속도라면야 조만간 그정도 속도야 충분히 뒤집고도 남습니다.
지금은 약간 비디오 렌더링 속도가 차이가 있긴 하지만.. 윈도처럼 직접 쓰나 뭐 중간에 잠시 거치나.. 씨퓨 속도가 3기가에 비디오 카드가 요즘 하이엔드급쯤 되도 유저가 그 속도차를 느낄수나 있을지요.
지금도 사실 왠만하면 그차이를 느끼는 사람은 드뭅니다. 그걸 따지고 드는 전문 개발자가 아닌한.. 안그런가요
여지껏 전 한번도 못느꼈습니다.
전문가는 아니지만 속도차이는 확실히 많이 나더군요.
사실 AT를 쓰고 있을때 486급에서 dir를 눌러보고는 놀라서 자빠지는줄 알았죠. :-)
엄청난 속도차이가 보이더라는 겁니다. 그런데 이 486에 익숙해지니 펜티움이나오고
펜티움에서의 dir은 더욱 놀라웠지요.
요즘은 화면에 그려지는 선하나하나를 따지는 시대는 지나가서 전체적인 모습이 눈앞에
보일때 까지의 시간을가지고 속도를 평가하는 것으로 보입니다만 앞으로 더 많은
집적도의 IC들이 나오면 분명히 하드웨어의 속도차이는 분명히 보입니다.
주제가 X와 MS-Windows였군요...
X가 느리다고는 하지만 오래사용한 MS-Windows보다는 빠르다고 생각합니다.
시간이 지나면 지날수록 시작시에 무엇을 그리 많이 작업하는지 MS-Windows는 상당한
끈기를 요구하게 되더군요.
아직도 MS-Windows를 사용하고 있지만 5~6개월정도 사용하면 부팅될때의 속도가
부담이 되어서 옛날 허큘레스의 전설이 생각날 정도죠.(컴퓨터켜고 밥을 먹는다는...)
이건 분명 MS사에서 무언가 조치가 필요하다고 생각되는 단점중에 하나입니다.
데스크탑으로써 MS-Windows는 상당히 좋은 OS이지만 시간이 지나가면 지나갈 수록
나이가 먹는 OS는 별로 바람직하지 않다고 생각되어집니다.
물론 모든 물건이 시간이 지나면 재성능을 내지 못한다는것은 일반상식이지만
소프트웨어까지 그런 법칙을 적용시켜놓는다는건 안좋다고 생각됩니다. :(
X도 KDE나 GNOME과 같은 WM를 사용할때 엄청나게 느린것은 많은 수정이 되어야겠지만
그리 수정되어질것 같질 않군요.
아~ 지금위에 적은글은 사용상에 나타나는 현상이 아니라(약간은 포함되겠지만...) 부팅될때의
현상을 푸념해본겁니다. :D
저는 엑스역시 상당히 불안한 소프트라고 생각합니다. 흔히 윈도우를 비판할때 블루스크린을 많이들 얘기하는데 x도 작업내용을 돌려주지 않아서 멈춰버리는 경우가 곧잘 있습니다. 이런 경우 xkill이라는 강력한 해결책이 있긴 하지만 그조차도 안되는 경우에는 ctrl+alt+backspace로 아예 엑스윈도우를 종료시킨 후 재시작 하면 해결되기는 하지만 x위에서 돌아가고 있던 프로세스들은 단번에 종료되기 때문에 x윈도우를 기반으로 사용하는 저같은 사용자의 경우에 컴퓨터의 리셋버튼을 누르는 것과 다름없는 상황입니다. 오히려 2000이나 xp의 블루스크린보다 더 잦은 리셋을 하는 것 같습니다. ctrl+alt+del만큼이나 ctrl+alt+backspace키 조합이 손에 익을 정도니 말이죠
데스크탑 혹은 워크스테이션으로서의 Linux혹은 BSD의 문제점 중 하나는 Windows계열에 비해 느린 GUI의 성능입니다.
위 목적으로 사용되는 기계에서 굳이 X처럼 C/S구조일 필요도 없을 듯 한데요...
Mac OS/X처럼 새로운, X기반이 아닌 GUI가 있었으면 하는데,
여러분들의 의견을 듣고 싶습니다.
DirectFB가 있습니다.
그리고, directFB 사이트에 가보면,
directFB기반의 배포본 링크도 있습니다. :wink:
위의 어느 분께서 말씀하셨듯이, X가 느린 것이 문제라는 것은
어차피 하드웨어 성능이 더 향상되면, 언제가 사라질 화제라는 것에
동감합니다.
그리고, X의 C/S 구조를 활용하는 일이 적어서
지금은 돼지의 진주처럼 여겨질 뿐이지,
만약 이것이 보편화가 된다면,
어쩌면
cygwin에 느리게 돌아가는 X서버를 투정하거나,
혹은 상용소프트웨어에 돈을 지불하거나 하며,
M$를 욕하면서,이 구조에 감사하게 될 일도 생길 수 있습니다.
데스크탑 혹은 워크스테이션으로서의 Linux혹은 BSD의 문제점 중 하나는 Windows계열에 비해 느린 GUI의 성능입니다.
위 목적으로 사용되는 기계에서 굳이 X처럼 C/S구조일 필요도 없을 듯 한데요...
Mac OS/X처럼 새로운, X기반이 아닌 GUI가 있었으면 하는데,
여러분들의 의견을 듣고 싶습니다.
DirectFB가 있습니다.
그리고, directFB 사이트에 가보면,
directFB기반의 배포본 링크도 있습니다. :wink:
위의 어느 분께서 말씀하셨듯이, X가 느린 것이 문제라는 것은
어차피 하드웨어 성능이 더 향상되면, 언제가 사라질 화제라는 것에
동감합니다.
그리고, X의 C/S 구조를 활용하는 일이 적어서
지금은 돼지의 진주처럼 여겨질 뿐이지,
만약 이것이 보편화가 된다면,
어쩌면
cygwin에 느리게 돌아가는 X서버를 투정하거나,
혹은 상용소프트웨어에 돈을 지불하거나 하며,
M$를 욕하면서,이 구조에 감사하게 될 일도 생길 수 있습니다.
개인적으로 몇번 써 본 경험에도 X는 불안정하고 윈도보다 느린구석이 있습니다. :( (이젠 Ctrl+Alt+Backspace 누르기 싫어요~)
하드웨어의 발전으로 언젠가는 사라지겠지만, 컴퓨터를 계속 주기적으로 업그레이드하는사람은 오히려 흔치 않습니다. 하드코어게이머나 IT관련 종사자의 경우 컴퓨터를 주기적으로 업그레이드해서, 시대에 발맞춰 컴퓨터를 개조해나가지만 일반 라이트 유저의 경우 이미 골동품이 된 컴퓨터를 4년~5년 써오고 있습니다. 펜II 유저도 아직 많고요. 펜3 캣마이 유저는 더 많습니다.
X의 서버-클라이언트방식은 확실히 장점이 많지만서도 라이트 유저를 위한 다른 체제 하나쯤은 있어도 좋을것도 같습니다.
개인적으로 몇번 써 본 경험에도 X는 불안정하고 윈도보다 느린구석이 있습니다. :( (이젠 Ctrl+Alt+Backspace 누르기 싫어요~)
제 생각에 X를 불안하게 만드는 가장 큰 원인은
불완전한 드라이버 문제가 가장 큰 것 같습니다.
X가 지원이 잘되는 그래픽 카드 사용자인 저는
X서버 리셋이 ctrl+alt+backspace라는 것을
기억을 못해낼 정도로 리셋을 누르는 것이 드믑니다.
참고로 저는 매트록스 사용자입니다.
Fedora Core 3 출시 하자마자 설치하고 나서
크래쉬가 아니라 한글관련 설정을 다시 불러오기 위해 한번 누르것 외에는
단 한차례도 없었습니다.
실제로 그 때 키가 기억이 안나서
Ctrl+alt+누머릭패드의 플러스 키를 누르고 리셋이 된 걸로
오해해서, 한참 삽질을 했었죠...
(그 전에 레드헷7.2를 사용했는데 X서버가 크래쉬해서
ctrl+alt+backspace를 눌렀던 기억이 거의 없습니다.)
이러한 문제는 X의 근본적인 문제보다는
부족한 써드파티나 메이저 밴더들의 지원에 기인하고
있을 가능성이 높습니다.
khris wrote:
X의 서버-클라이언트방식은 확실히 장점이 많지만서도 라이트 유저를 위한 다른 체제 하나쯤은 있어도 좋을것도 같습니다.
하나쯤이 아니라 꽤 많습니다.
위의 언급되어진 DirectFB만 아니라..
임베디드 시스템을 위한 QT기반의 GUI도 있는 것로 알고 있습니다.
DirectFB 로 X 를 띄울려면 XDirectFB 라는 레이어가 필요합니다.
XFree 나 Xorg 의 소스에 패치를 해서 DirectFB 위에 X 를 띄웁니다.
그런데 저 XDirectFB 라는 프로젝트가 2년넘게 진척이 없거든요.
개발자가 손을 떼 버린건지... :?
보아하니 DirectFB 도 기존 PC에서 구현보다는 하드웨어자원이 부족한 임베디드시스템에서의 활용쪽으로
방향을 바꾸는 것 같습니다.
현재 Kdrive는 XServer라는 이름으로 Freedesktop 쪽에서 작업하고 있습니다.
Quote:
The X server project holds sources to build an X server separately from a full X distribution. The only drivers supplied are based on the kdrive framework.
최근 몇몇 리눅스 배포판(Novell Ximian, Fedora/RedHat)쪽에서 Xserver를 기반으로 하는 아래의 프로젝트를 이용해서 차기(?) 데스크탑 환경을 준비중입니다.
저는 엑스역시 상당히 불안한 소프트라고 생각합니다. 흔히 윈도우를 비판할때 블루스크린을 많이들 얘기하는데 x도 작업내용을 돌려주지 않아서 멈춰버리는 경우가 곧잘 있습니다. 이런 경우 xkill이라는 강력한 해결책이 있긴 하지만 그조차도 안되는 경우에는 ctrl+alt+backspace로 아예 엑스윈도우를 종료시킨 후 재시작 하면 해결되기는 하지만 x위에서 돌아가고 있던 프로세스들은 단번에 종료되기 때문에 x윈도우를 기반으로 사용하는 저같은 사용자의 경우에 컴퓨터의 리셋버튼을 누르는 것과 다름없는 상황입니다. 오히려 2000이나 xp의 블루스크린보다 더 잦은 리셋을 하는 것 같습니다. ctrl+alt+del만큼이나 ctrl+alt+backspace키 조합이 손에 익을 정도니 말이죠
저는 이 의견에 반대입니다. luark 님이 그러하시다면
그것은 X 자체 문제가 아닐것입니다. 왜냐면 전 그놈 데스크탑으로 작업은 주로 코딩작업과 영화, 음악을 듣는데 업타임 한달씩 쓰기
때문입니다.
프레임버퍼는 하드웨어에 대한 제어를 추상화해놓은 것이라고 보면 됩니다.
하드웨어를 직접 제어하는 것 보다 편하게 하기 위해서 미리 함수를 만들어 놓는 거죠.
예를 들어 사각형그리기는 DrawRect(), 노란색 채우기 FillYellow() .... 등등 이런식으로요.
물론 프레임버퍼위에 작동하기 위해서 코드를 새로 작성해야 됩니다.
XDirectFB 는 DirectFB 상에서 X 를 구동하기 때문에 Gnome,KDE,fluxbox 등 모두
다 쓸수 있습니다. XDirectFB 는 실시간 알파채널랜더링이 되어서 모든 창이 투명하게 되는데
이게 정말 뽀대(?)가 나죠.
그리고 DirectFB 를 쓸때 장점은 굳이 X 를 띄우지 않아도 여러가지를 할수 있는게 좋습니다.
mplayer 의 dfbmga 드라이버로 TV출력,
콘솔에 만화보기 DFBSee,
로그인매니저 Qingy,
XML 형식 프리젠테이션 DFBPoint,
links 의 direcffb 드라이버로 웹브라우징,
directfb 드라이버를 지원하는 게임라이브러리 clanlib 을 사용하는 게임 ex. clanbomber (크레이지아케이드 같은거)
등등..
----------------------------------------
Nothing left after Nirvana.
저는 엑스역시 상당히 불안한 소프트라고 생각합니다. 흔히 윈도우를 비판할때 블루스크린을 많이들 얘기하는데 x도 작업내용을 돌려주지 않아서 멈춰버리는 경우가 곧잘 있습니다. 이런 경우 xkill이라는 강력한 해결책이 있긴 하지만 그조차도 안되는 경우에는 ctrl+alt+backspace로 아예 엑스윈도우를 종료시킨 후 재시작 하면 해결되기는 하지만 x위에서 돌아가고 있던 프로세스들은 단번에 종료되기 때문에 x윈도우를 기반으로 사용하는 저같은 사용자의 경우에 컴퓨터의 리셋버튼을 누르는 것과 다름없는 상황입니다. 오히려 2000이나 xp의 블루스크린보다 더 잦은 리셋을 하는 것 같습니다. ctrl+alt+del만큼이나 ctrl+alt+backspace키 조합이 손에 익을 정도니 말이죠
제 경우에는 파폭이 문제입니다. 데비안 testing 버전을 쓰고 있는데 배포판의
파폭이 램을 스왑까지 99% 먹어버리곤 리ㅤㅅㅔㅌ을 해야하는 경우로 치닫습니다.
10분을 기다리고 20분을 기다려도 하드 스왑으로 인한 디스크 액세스만 끝없이
계속 하더군요.
또 루x웹 이니 하는 특정 게시판에서 메모리 점유율이 악몽과도 같이 올라가서
상당히 반응 속도가 처지는 것을 매일 같이 경험합니다. 윈도즈에서의 파폭의
높은 메모리 점유율을 토로하는 유저의 글이 가끔 올라오는 걸 보면 이 부분은
개선의 여지가 있는 듯 싶습니다.
파폭 말고는 엑스 윈도 자체는 괜찮은 듯 싶더군요. 루크옹은 어떤 넘이 말썽을
부리시는 건지 알고 싶군요. :D
X-windows의 속도나 그런것들을 문제삼으시는 분들도 있는데...
몇가지 나름대로의 전제를 세우고 시작해보겠습니다.
1. X-windows는 충분히 빠르다
2. 현재시점에서야말로 X-windows의 network model은 충분히 유용하다.
3. X-windows가 불안한 이유는 과연 무엇인가?
이 세가지에 대해 나름대로 얘기를 해보겠습니다.
1. X-windows는 충분히 빠르다.
무겁다고 생각되는건 gnome이나 kde를 사용해서 벌어지는 일이 대부분이라는게 제 생각입니다. 물론 저도 gnome을 사용하기는 합니다만... 무겁습니다. gnome이 windows보다 무거운건 맞습니다만... X-windows자체가 무거운건 아닙니다. 특히 opengl 하드웨어가속은 ms-windows보다 더 빠르다고 생각됩니다.
2. X-windows의 network model
이것은 대단히 중요한 의미를 가집니다. 물론 어떤 분들은 전혀 쓸모없는거라 말씀을 하시기도 합니다만... 하드웨어 리소스가 제한될수록 더더욱 진가를 발휘합니다. 아무리 뒤떨어진 OS라도 X-windows server만 있으면 linux에서 최신의 application들을 땡겨와서 사용할 수 있습니다. 그것도 linux가 돌아가고 있는 컴퓨터의 사용이 좋으면 좋을수록 더 빠른 반응을 얻을 수 있습니다. 물론 구조적인 문제점이 전혀 없다고 하면 거짓말일 수도 있겠습니다만.. 최소한 windows의 RDP보다는 훨씬 좋은놈이라 생각합니다. (하긴.. rdp는 사운드가 나오니깐... RDP가 더 좋을라나요...?)
3. X-windows가 불안정하게 생각되는 이유
X-windows는 기본적으로 대단히 안정적인 시스템이라 과히 자부합니다. 문제가 있는 경우는 이미 다른분들이 말씀하셨지만 굳이 정리하자면 다음과 같습니다.
1) X-windows상에서 작동되는 어플리케이션의 불안정함
2) 하드웨어의 불안정함
3) Driver등의 불안정함
난데없이 웬 하드웨어가 등장하는것인가.... 라는 분들이 계실텐데.. 제 경험상 linux는 windows보다 하드웨어상태에 더 민감한 OS라고 생각됩니다. LFS부터 빌드를 하거나 젠투를 stage1부터 빌드를 해보면 더 극명히 드러나는데.. 제 경우는 이런 불안정성때문에 하드웨어를 바꾸면 항상 테스트를 해보는 편입니다.
application은 말할것도 없고 firefox가 cpu를 많이 먹으면서 뻗는건 대개 plugin의 문제입니다. 제 경험으로는 초기에는 mplayerplug-in이 문제였었고 요즘은 flash plugin이 여러 tab을 열면 cpu를 많이 드시면서 저승으로 가십니다.
driver의 불안정함은.. 아마 다들 아실겁니다. 그나마 잘 제공되는 nvidia driver마저도 버전에 따른 차이를 보입니다.. 무서워서 최선버전은 잘 못쓰는 편이거든요....-.-;
4. 기타사항
x-windows의 대안품들은 예전부터 있었습니다. 지금이야 아예 이름이 바뀌어서 다른쪽에서 사용되고 있지만.. 원래 berlin이라는 프로젝트가 있었죠. 현재는 BeOS의 clone인 HAIKU의 display 엔진으로 사용되고 있는걸로 알고있습니다. directfb보다 훨씬 먼저 나왔던 X-windows의 대안이었습니다.
뭐 이런논의가 항상 그랬듯이.. 플레임성의 위험을 가지고 있는건 사실입니다. 정보와 의견으로 좋은 토론이 되었으면 합니다.
엑스윈도우즈는 현재도 충분히 빠르다고 생각합니다.
현재 윈도우즈 상에서 아무것도 띄워 놓지 않은 상태에서 돌려도 그놈 환경이라도 확실히 빠르게 느껴집니다.파폭 구동속도도 윈도우즈의 그것 보다 훨씬 빠른 편입니다.다만 문제라면 제대로된 그래픽 가속을 지원해주는 드라이버가 많이 존재하지 않는 다는게 문제가 아닐까요...?
최근 쓰는 프로그램 중에서는 totem이 가장 말썽을 부리더군요. 종료시키면 화면이 먹통이 되면서 소리는 계속나는 난감함.. 다른 가상데스크탑으로 이동해서 터미널 띄운 후 killall totem으로 해서 해결하곤 합니다만..; 처음에는 무작스럽게 엑스리셋을 시키곤 했었죠.;(저 글 쓸 당시;;)
"X Window System" is commonly shortened to "X11" or simply "X". The term "X Windows" (in the manner of "Microsoft Windows") is officially deprecated and generally considered incorrect, though it has been in common use since the inception of X and has been used deliberately for literary effect, for example in the Unix-Haters Handbook.
그리고, 제가 보았던 맞춤법에서는 '윈도우'가 아니라 '윈도'를 옳은 표기라고 했는데, 맞춤법이 자주 바뀌어서 요즘은 모르겠네요. 자세히 아시는 분이 고쳐 주셨으면 좋겠습니다.
그것도 linux가 돌아가고 있는 컴퓨터의 사용이 좋으면 좋을수록 더 빠른 반응을 얻을 수 있습니다. 물론 구조적인 문제점이 전혀 없다고 하면 거짓말일 수도 있겠습니다만.. 최소한 windows의 RDP보다는 훨씬 좋은놈이라 생각합니다. (하긴.. rdp는 사운드가 나오니깐... RDP가 더 좋을라나요...?)
엑스윈도우즈는 현재도 충분히 빠르다고 생각합니다.
현재 윈도우즈 상에서 아무것도 띄워 놓지 않은 상태에서 돌려도 그놈 환경이라도 확실히 빠르게 느껴집니다.파폭 구동속도도 윈도우즈의 그것 보다 훨씬 빠른 편입니다.다만 문제라면 제대로된 그래픽 가속을 지원해주는 드라이버가 많이 존재하지 않는 다는게 문제가 아닐까요...?
X의 network model은 제게는 정말 유용합니다.
전 R의 통계패키지를 이용해서 plot을 많이 그립니다.
메모리가 많이 필요하기 때문에 IBM 64bit 서버의 8G 메모리를 써야 합니다.
윈도우에 Xmanager란 Xserver프로그램을 설치하구요. 터미널로 접속해서 코드를 입력하면 윈도우에 그림창이 뜹니다. 계산은 서버에서 보는건 개인pc에서 첨엔 넘 신기하더라구요. 옛날에 어떻게 이렇게 시스템 디자인할 생각을 했는지..^^ firefox도 (사실 전 opera를 선호합니다.) 서버의 application을 윈도우에 띄워서 사용합니다. 이렇게 하니 개인pc에 linux를 설치할 일이 정말 없더군요. 딱 한가지 아쉬운 거는 이런 구조면 터미널의 screen 같은게 가능할 것 같은데 (X의 작업을 저장했다. 나중에 다른 곳에서 접속해서 보는) 못 찾겠더라구요. 이것만 되면 최상의 작업환경인데...
PC에 X 서버를 깔아놓고 외부의 프로그램 화면을 볼 때에 RENDER extension이 필요한 경우가 있습니다. 요즈음 데스크탑 환경의 프로그램은 대부분 RENDER extension이 필요하죠.
이 경우에 이 extension이 없는 X 서버를 사용하면 보이긴 하지만 무지하게 느립니다. 저번에 사용해본 바로 Xmanager는 RENDER extension이 없는 듯 하더군요. Xmanager로 딴 컴퓨터의 GNOME session을 통째로 띄워본 일이 있었는데 (테스트로...) 무지하게 느려서 사용할 수가 없었습니다. 그런데 cygwin X는 나름 쓸만한 속도가 나오더군요. cygwin X는 RENDER extension을 지원합니다.
속도 차이가 장난이 아니니 혹시 원격으로 띄울때 속도때문에 좌절한 분은 이 문제가 아니었나 고려해 봄직도 하네요 ^^ 그렇다고 GNOME session을 통째로 띄워서 사용할 정도는 아직 아니구요. 프로그램 하나 둘 띄워 쓰는데는 큰 불편함이 없습니다.
X에서도 windows의 remote desktop처럼 최적화된 원격 접속 기능이 있었으면 정말 좋겠네요 :)
엑스윈도우즈는 현재도 충분히 빠르다고 생각합니다.
현재 윈도우즈 상에서 아무것도 띄워 놓지 않은 상태에서 돌려도 그놈 환경이라도 확실히 빠르게 느껴집니다.파폭 구동속도도 윈도우즈의 그것 보다 훨씬 빠른 편입니다.다만 문제라면 제대로된 그래픽 가속을 지원해주는 드라이버가 많이 존재하지 않는 다는게 문제가 아닐까요...?
3dfx Banshee/Voodoo3, 4, 5
ATI Mach64 (Rage Pro)
ATI Rage 128 (Standard, Pro, Mobility)
ATI Radeons up to 9200 are supported
Intel 810, i810-dc100, i810e, i810e2, i815, i815e, i830, i845, i852/855, i865, i915
Matrox g200/g400/g450/g550
S3 Savage3D, SavageMX/IX, Savage4, Supersavage, Prosavage/Twister/DDR
SiS 300/305, 540, 630/730
Via CLE266, Castlerock, Unichrome, ProSavage-DDR400
ATI그래픽 카드 사용자는 확실히 이부분에서 공감하실것 같구요.
우선 그들이 말하는 flgrx의 적용 범위가 적다는 것입니다.엔비디아는 모르겠지만 ATI는 모바일계열은 하이엔드 그래픽 사용자를 제외한 구형 노트북 사용자들은 ATI드라이버로 지원되지 않을 뿐더러 지원할 생각도 없는 것 같습니다.오픈지엘로 돌린다고 해도 분명 제 노트북은 툭스레이서 정도는 돌릴 사양입니다.HP 사이트가면 드라이버 찾아봐도 운영체제는 2000 그리고 엑스피(이 드라이버로 설치하면 2003에서도 가속이 됩니다. :D ) 에서 구동되는 드라이버가 전부이고 리눅스 드라이버는 찾아 볼수도 없습니다.엔비디아가 장착되어 있는 데탑 두곳에서는 네버윈터 나이츠도 즐기고 하는데 노트북에서는 절망뿐입니다.웹사이트 우분투 포럼 드라이버를 찾아 다녔지만(여기도 질문 두번이나 올렸지만 답변은 없었습니다.) 역시 절망이더군요..
그리고 설치도 그렇게 용이한편도 아닙니다.엔비디아의 그래픽 드라이버는 약간의 불편(윈도우즈버전보다는 불편한면이)이 있지만 쉽게 설치하고 업데이트도 용이하고 쉽게 세팅하고 잘 사용할수 있지만 ATI드라이버는 섬세하기도 하거니와 또한 설치도 용이하지 않습니다.
지원된다는 의미에서는 ATI가 들어갈지도 모르지만 잘사용하기에는 몇몇 하드웨어 엑스윈 서버를 제외하고 글러먹은 드라이버가 ATI입니다.
PS:현재 노트북에 특이한 하드웨어 두개가 장착되어 있습니다.하나는 MD고 두번째는 ACECAD II 시리얼버전입니다.이두개는 하드웨어 문제없이 리눅스 상에서 돌아갑니다.엠디는 장착하자 마자 쓰기 읽기가 가능했고(하이엠디라서 일반 데이터도 엠디에 저장이 가능합니다) ACECAD II는 삽질은 조금 했지만 지금은 잘 사용할수 있습니다만 ATI 그래픽 카드는 삽질을 해봐도 나아지는 기색이 없습니다. :cry:
저도 X가 아니라 KDE, GNOME이 느리다는 생각을 합니다. 가벼운 윈도우 매니저를 쓸 때는 체감 속도가 윈도우보다 빠르거든요. KDE, GNOME도 영문으로 쓸 때는 윈도우보다 빠를 때가 있습니다. 한글 폰토의 랜더링 속도에 문제가 있지 않나 하는 생각도 좀 해봅니다.
근데 웬지 리눅스 데스크탑으로 오래 작업하면 윈도우할 때보다 눈이 더 아픕니다. 그런 거 느끼신 분 없나요? 폰트를 꽤 여러 가지로 바꿔보고 윈도우 TTF 끌어와서도 써보고 했는데 뭔가 좀 이상하네요. 리프레시 레이트도 조정해봤는데 이게 조정이 되는 건지 아닌지 잘 모르겠더라는-_- 이런 거 느끼신 분들 어떻게 해결하고 있으신지 궁금하네요.
X의 network model은 제게는 정말 유용합니다.
전 R의 통계패키지를 이용해서 plot을 많이 그립니다.
메모리가 많이 필요하기 때문에 IBM 64bit 서버의 8G 메모리를 써야 합니다.
윈도우에 Xmanager란 Xserver프로그램을 설치하구요. 터미널로 접속해서 코드를 입력하면 윈도우에 그림창이 뜹니다. 계산은 서버에서 보는건 개인pc에서 첨엔 넘 신기하더라구요. 옛날에 어떻게 이렇게 시스템 디자인할 생각을 했는지..^^ firefox도 (사실 전 opera를 선호합니다.) 서버의 application을 윈도우에 띄워서 사용합니다. 이렇게 하니 개인pc에 linux를 설치할 일이 정말 없더군요. 딱 한가지 아쉬운 거는 이런 구조면 터미널의 screen 같은게 가능할 것 같은데 (X의 작업을 저장했다. 나중에 다른 곳에서 접속해서 보는) 못 찾겠더라구요. 이것만 되면 최상의 작업환경인데...
VNC 쓰세요. 작업하다가 접속중단하고 딴곳에서 다시 그화면 그대로 접속할 수 있습니다. 물론 어플은 고대로 돌고 있지요.
근데 웬지 리눅스 데스크탑으로 오래 작업하면 윈도우할 때보다 눈이 더 아픕니다. 그런 거 느끼신 분 없나요? 폰트를 꽤 여러 가지로 바꿔보고 윈도우 TTF 끌어와서도 써보고 했는데 뭔가 좀 이상하네요. 리프레시 레이트도 조정해봤는데 이게 조정이 되는 건지 아닌지 잘 모르겠더라는-_- 이런 거 느끼신 분들 어떻게 해결하고 있으신지 궁금하네요.
저는 개인적으로 X는 정말 문제가 많다고 생각합니다. X의 문제인지, XFree86의 문제인지, 아니면 윈도우 매니저의 문제인지, 어플리케이션의 문제인지, 드라이버의 문제인지는 잘 모르겠습니다만... 어쨌거나 X가 기본 구조 상 상당한 오버헤드를 가지고 있다는 걸 부정할 수는 없다고 봅니다. 장점도 많지만 말입니다.
그런데 X를 옹호하는 쓰레드를 다는 분들의 논리는 수긍하기 어렵습니다. X가 오버헤드가 많은 건 사실이지만, 하드웨어 성능이 좋아지고 있으니까 문제가 안 된다... 만약 M$에서 그렇게 말했다면, 아마 여기 게시판에 불이 나겠지요. 거봐라, 실력이 안되니까 별 해괴한 핑계를 다 댄다, 꼭 최신 사양으로 컴을 꾸미라는 법 있냐...
그렇게 말한다면, X의 약점이자 강점인 C/S 구조도 더 이상 강점이 아닙니다. M$도 개념은 다르지만 리모트 터미널 기능이 있습니다. 훨씬 무겁습니다. 하지만 뭐가 문제랍니까? 하드웨어 좋은 걸 쓰면 되는데... 기가비트 랜카드도 2, 3만원 밖에 안 하는데...
X가 효율적이냐 아니냐 느리냐 안 느리냐 라는 점보다, 유저 데스크탑 환경이라는 좀더 큰 틀에서 문제를 봐야 하지 않겠습니까? 사용자 편의성, 속도, 안정성, 한글 입출력(이거 정말 불만 많습니다), 시각적인 만족감, 다양한 어플리케이션의 지원, 어플리케이션의 안정성, 비용(금전적인 면과 시간적인 면 모두)....
(이렇게 말하면 플레임이 될 지도 모르겠습니다만) 리눅스가 언제까지 구루들의 장난감으로 자족한다면 구태여 이런 말 하는게 무의미 하겠지만 말입니다.
저는 개인적으로 X는 정말 문제가 많다고 생각합니다. X의 문제인지, XFree86의 문제인지, 아니면 윈도우 매니저의 문제인지, 어플리케이션의 문제인지, 드라이버의 문제인지는 잘 모르겠습니다만... 어쨌거나 X가 기본 구조 상 상당한 오버헤드를 가지고 있다는 걸 부정할 수는 없다고 봅니다. 장점도 많지만 말입니다.
위에도 잠깐 나왔지만 우선 저나 몇몇 다른 분들이 모두 'X가 기본 구조상 오버헤드가 크다'라는 전제를 snoman님과 같이 당연하게 받아들이고 있지 않다는 점을 주목해 주시기 바랍니다. 저도 그 부분에 대한 설득력 있는 근거가 있다면 알고 싶습니다만, 그런 근거가 없기 때문에 저런 전제를 받아들이지 못한다고 해서 모두가 snoman님께서 말씀하시는 것처럼 '억지'를 쓴다고 볼 수는 없다고 생각합니다.
윗분께서도 지적하셨 듯이 단순히 같은 사양 컴퓨터에 리눅스를 깔면 GUI 반응이 윈도우즈보다 못한 것 같다는 느낌 만으로 그걸 X의 구조적 문제 때문으로 단정할 수 없습니다.
글꼴 처리 방식, 데스크탑 환경의 구현 문제, 사용한 그래픽 드라이버의 수준 등등 수 많은 변수가 있기 때문에 그런 주장을 위해서는 보다 객관적이고 검증 가능한 근거가 필요하다고 봅니다.
---------------------------- [서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...
fender님, 오버헤드의 정의가 다시 필요한 건 아니겠지요? 그런 의미로 쓰신 건 결코 아닐 거라고 생각합니다. 다이렉트 렌더링 이야기가 왜 나왔는지 모르는 분도 아닐 테니 그 얘길 반복할 필요도 없구요. x 개발자 내부에서도 오래 전부터 이야기되어 왔던 부분입니다.
오히려, 오버헤드가 크지 않다고 생각하시는 분들이 오버헤드가 크다는 주장에 반론을 제시하셔야 하는 게 아닐까요? "보다 객관적이고 검증 가능한 근거"를 가지고서요.
계층이 늘어나면 '오버헤드'가 생긴다는 건 상식적입니다만, 그게 '상당한 오버헤드'가 될는지는 데이터가 없으면 알 수 없습니다.
여기서 말하는 '상당한'은 구체적으로 동일한 조건 하에서 동일한 GUI 응용 프로그램을 구동했을 때 사용자가 불편함을 느낄 수 있을 만큼의 속도 저하가 있는 것으로 가정해야 할 것입니다. 또한 안정성 문제도 나왔으니 성능 이외에 그런 계층의 추가로 인해 혹시 사용자가 느낄 수 있는 정도로 동일한 응용프로그램이 자주 오동작을 하거나 죽는 경우가 발생하는 경우를 말합니다.
이렇게 봤을 때 윈도우즈와 리눅스 등의 X윈도우 시스템 간의 오버헤드를 일반 사용자가 체감하는 건 사실상 어렵습니다. 왜냐하면 일단 '동일한 조건'이라는 것 자체를 충족하려면 예를들어 단순히 윈도우즈에서 모질라 더블 클릭해보고 그놈에서 클릭해보는 수준으로 판단 가능하지 않기 때문입니다.
같은 응용프로그램이라도 윈도우즈와 그놈/KDE 간에 사용한 비디오 카드 드라이버의 성능/안정성이 다를 수도 있고 글꼴 처리 방식이 다를 수도 있습니다. 반면 저 같은 경우는 오히려 예를들어 3D 크로스 플랫폼 게임을 양쪽에서 돌려 보거나 동영상을 재생해 보아도 별다른 FPS 차이를 느끼지 못하겠더군요.
한 가지 오해를 없애기 위해 말씀드리자면 이 문제에 대해 저는 snoman님이나 다른 분들 이상으로 아는 바가 없습니다. 다만 이제까지 "윈도우즈가 리눅스보다 GUI 성능이 월등하다"라던가 그 이유가 구체적으로 'X 윈도우가 네트워크 기반 설계를 채택했기 때문'임을 입증할 설득력 있는 근거를 본적이 없을 뿐입니다.
오히려 위에도 링크가 있지만 왜 네트워크 기반이라 느리다는 것이 근거없는 'myth'인지에 대한 이야기는 본적이 있습니다.
다시 말씀드리면 이 문제에 대해 제가 원하는 건 무조건 X윈도우가 좋다는 걸 인정시키는게 아니라 단지 '내가 써보니까 윈도우즈가 훨씬 빠르더라', 아니면 '네트워크 거치면 당연히 느린거 아니냐?'하는 이상의 어떤 설득력 있는 근거입니다.
---------------------------- [서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...
오버헤드와 안정성은 일단 별개의 문제인 것 같습니다. 제 생각에 오버헤드는 크게 두 가지를 들 수 있다고 생각합니다. 성능의 저하와 리소스(메모리, CPU ...) 점유율입니다. (물론 개발이나 유지보수의 오버헤드도 있습니다만, 개발자가 아닌 이상 상관 없으니 패스)
X 윈도우가 네트워크 기반이지만 빠르다는 건 unix domain socket이 tcp socket과 비교해서 빠르다는 거지, 다이렉트 렌더링보다 빠르다는 건 아닙니다.
예전에 단순히 Hello, world를 출력하는 프로그램을 QT로 만들어서 M$ 윈도우와 X에서 컴파일해서 돌려봤습니다. 메모리 점유율은 M$ 윈도우의 경우 8MB 정도, X는 16~17MB 정도였습니다. X 자체의 문제인지, solaris의 문제인지, xlib의 문제인지, QT의 문제인지는 모르겠습니다.
그리고 설득력 있는 근거는 xfree86 개발자 포럼에 이미 올라와 있습니다. 궁금하시면 참고하시길....
X 윈도우가 네트워크 기반이지만 빠르다는 건 unix domain socket이 tcp socket과 비교해서 빠르다는 거지, 다이렉트 렌더링보다 빠르다는 건 아닙니다.
그게 '얼마나' 빠른지가 문제 아닐까요? 흔히 하는 이야기로 예를들어 A라는 언어가 B라는 언어보다 GUI에서 10배가 빠르다면 엄청난 것 같지만 그 결과가 만약 버튼을 눌렀을 때 결과가 나오는 시간이 A 기반 응용프로그램은 0.001초, B가 0.01초라면 일반 사용자 입장에선 전혀 의미가 없습니다. 둘 다 '충분히 빠른' 결과이기 때문입니다.
만약 GUI 반응속도에서 현저한 차이가 난다면 그건 최소한 0.05초 대 1-2초 정도가 되어야 의미가 있는 것입니다. 그리고 이 논의에서는 단순히 domain socket을 쓰는 것보다 다이렉트 렌더링이 빠르다는 것보다는 과연 그 속도 차이가 실제 사용자에게 느껴질 정도로 큰 것인지가 중요하지 않나 싶습니다.
Quote:
예전에 단순히 Hello, world를 출력하는 프로그램을 QT로 만들어서 M$ 윈도우와 X에서 컴파일해서 돌려봤습니다. 메모리 점유율은 M$ 윈도우의 경우 8MB 정도, X는 16~17MB 정도였습니다. X 자체의 문제인지, solaris의 문제인지, xlib의 문제인지, QT의 문제인지는 모르겠습니다.
글쎄요... 저도 모르겠군요 :) 다만 그게 처음 말씀하셨던 'X윈도우의 구조적인 문제점'을 증명하는 근거가 될 것 같지는 않습니다.
Quote:
그리고 설득력 있는 근거는 xfree86 개발자 포럼에 이미 올라와 있습니다. 궁금하시면 참고하시길....
이 부분은 저도 무척 궁금합니다. 혹시 바쁘지 않으시면 링크라도 뿌려주시면 저나 다른 분들에게 도움이 될 것 같습니다.
---------------------------- [서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...
그냥 보이기에 M$윈도그와 X의 성능자체는 M$윈도그가 좋지 않습니까.
최대한 비슷한 환경을 꾸민다는 가정하에서 말입니다.
'플렉스박스정도 하나 뛰어 놓고 윈도우보다 속도가 빠르다.'라고 말하는 것은 억지로 밖에 보이지 않습니다.
그리고 C/S환경의 경우엔 이건 정말 어려워졌습니다. 현재의 X는 초기와는 다르게 돌아가고 있으니까요. 마치 윈도우 3.1에서 윈도우 95 혹은 98이 된 거처럼 하드웨어를 직접 접근하는 방식을 사용하게 됨으로서 성능 향상이 많이 되었고 윈도그와 개별적으로 비교할 경우엔 성능이 뛰어난 부분도 존재한다고 생각됩니다.
(얼마 전에 설치활용쪽에도 비슷한 쓰레드를 남겨서 X의 성능을 향상하는 방법에 대해서 알게 되었습니다. Gtk나 QT를 directFB계열로 돌리면 비약적인 퍼포먼스의 향상을 불러 올 수도 있겠더군요. 아직 시험해 보지는 않았습니다.)
fender님의 말씀처럼. X나 윈도그는 여러 프로그램들의 혼합이기 때문에 X자체의 구조를 따져서는 안 될 것 같기는 합니다. 그렇다고 해도 전체적인 성능은 떨어집니다.(위에 언급한 가정하에서 말이죠.) 이 눈에 보이는 차이 때문에 윈도그와 X의 확연한 차이점인 C/S구조가 문제가 아니냐고 생각하게 되는 것이죠.
그러나 사실 그럴 수밖에 없는 것이 X의 경우에 불특정 다수가 제작하는 프로그램이고 윈도그는 계획을 정하고 팀별로 프로그래밍하는 것에서 오는 차이일 수도 있고 계속 개발하는 프로그램이기 때문에 디버그코드들이 산재한데서 오는 문제 점일 수도 있는 것은 애석한 일이라고 생각합니다.
저는 일단 X < 윈도그라는 생각하는 부류입니다. GUI환경은 윈도그나 OSX쪽이 확실히 좋다고 생각합니다.(부팅속도를 따지는 것은 GUI와는 관련이 없으니.)
'현실은 수학으로 표현할 수 없다.'
'수학은 거짓의 학문이다.'
'난 수학이 정말 싫다.'
저도 fender님의 지적에 동의합니다. C/S 구조가 물론 그 자체로 다이렉트 랜더링보다 손해를 보는 구조임은 틀림 없습니다만 문제는 그 정도가 얼마냐 하는 것입니다. GUI가 구동되는 과정에서 그 통신 뿐 아니라 많은 단계에서 많은 비용이 소모됩니다. 만약 다른 단계에서의 비용이 통신 비용을 압도한다면 C/S로 추가비용이 발생하건 말건 별다른 문제가 안됩니다.
이를테면 J2EE에서 자바 단계에서 온갖 레이어를 다 겹쳐놔도 거기서 발생하는 비용은 데이터베이스에 쿼리 한 번 날리는 비용의 100분의 1도 안되는 경우가 많습니다. 이런 경우 자바단의 레이어들은 속도 결정 요인이 아니기 때문에 아무리 많이 레이어를 겹쳐놔도 전체 성능에 거의 영향을 주지 않습니다.
튜닝에서 제일 중요한 것은 속도 결정 요인을 찾아내는 것입니다. 속도 결정 요인이 아닌 것을 아무리 튜닝해봐야 시스템은 빨라지지 않습니다. X 서버 문제도 GUI가 돌아가는 전체 상황을 프로파일링한 데이터가 없이는 어떠한 논리도 '추측'에 불과합니다. C/S 비용이 폰트 랜더링 비용의 100분의 1일 수도 있는 거니까요.
물론, 저 역시 이 문제에 관한 어떠한 정확한 정보도 갖고 있지 않습니다. 다만 C/S 구조가 X의 치명적인 성능 문제를 야기한다고 주장하려면 단순히 통신하니까 더 느리겠지..정도로는 부족하다는 것을 말하고 싶습니다.
X가 C/S구조인건 개발되던 당시의 환경을 반영하고 있습니다(X터미널 등을 생각하시면 쉬울듯. 요즘 SBC라고 해서 또다시 부활하고 있지만...). 단순히 데스크탑에서 그래픽 카드의 성능을 최대한 이끌어내고 최대한 편리한 U/I에 초점을 맞춘다면 100% X가 안좋은 구조일 수 밖에 없지요.
MS도 원격 터미널 지원 등을 통해서 네트워크 구조를 극복하려는 노력을 하고 있습니다만, 윈도우 단위로 원격에서 불러다 자신의 데스크탑에 넣을 수 있는건 X밖에 없습니다. 그런 장점에 대해서 사용할 일이 없어진 (대부분 PC 1대에서 작업하는) 최근의 x86 리눅스|FreeBSD 사용자에게는 X의 C/S적인 특성은 있으나 마나한 것이니 비교가 무의미하겠지요.
속도가 개선되야 할 것 같다는 생각은 솔직히 들지만
개선되지 않는다고 하더라도 할말은 없습니다. 올챙이 개구리적
생각 못한다고 정말 예전에는 입에서 욕튀어나오면서 사용했었는데
이제는 조금 속도가 느려도 정말 사용할만 하다는 생각이 듭니다.
예전에는 사양이 월등히 좋은 PC 에서 리눅스를 돌려도 X 윈도우를
사용할때 어딘지 모를 어색함(?) 어정쩡함(?) 같은 느낌이 있었는데
거의 없어진 듯합니다. 다들 느끼실지 모르겠지만 거의 MS 윈도우의
데스크탑의 느낌을 살리려고 노력하는 듯이 보입니다. 체감으로 느꼈던 것은
좋은 마우스로도 느끼지 못했던 미묘한 마우스의 움직임과 커서움직임,
그외에 미묘한 메뉴 오픈과 창의 컨트롤 등등 그리고 메뉴의 구성이나
일반적인 어플리케이션의 응답 등등.. 이런 몸으로 느낄 수 있는 감각적인
부분이 솔직히 윈도우를 주 업무용으로 사용하는 사람들 한테 생기는 몸에 벤
감각적인 부분들이 많이 개선되어서 이제는 주 업무용으로 리눅스를 써도
되지 않을까란 생각이 많이듭니다. (제가 좀 특이해서 스타할때도 마우스 들고
다니는 지라.. ㅡ.ㅡ; 이런 부분에 딴지걸려도 할말은 없음... ㅎㅎ)
파폭으로 인터넷 업무보고 오픈오피스로 문서작성하고 wine 으로 노츠 클라이
언트 돌리면 업무를 X 윈도우 환경으로 사용해도 예전의 어정쩡함을 느끼지
못하니 개인적으로는 이만큼 발전시킨 개발자들에게 감사하게 생각되네요..
마지막 숙제로 파폭의 ActiveX 와 플래쉬 플러그인 문제만 해결된다면 갠적으로
겜을 많이 안하기 땜시 윈도우에서 리눅스 X 윈도우 환경으로 완전전향해도
되겠단생각이 듭니다. 여기까지는 어디까지나 일반사용자의 입장에서 만약에
MS 윈도우 대용으로 리눅스를 데스크탑으로 활용한다면? 이라는 가정하에
말씀 드리는 겁니다..
-------------------------------------------------------------
어쨌거나 저쨌거나 예전에 비하면 정말 감지덕지로 발전한
X 윈도우 시스템에 대해서 개인적으로 찬사를 보냅니다.
The device independence and separation of client and server does incur an overhead. X's network transparency requires the clients and server to operate separately. In the early days, this gave a significant performance penalty on a standalone system compared to Microsoft Windows or Mac OS (versions 1 to 9), where windowing was deeply embedded in the operating system. 4 to 8MB of RAM was recommended for reasonable performance; until the mid-1990s, this was regarded as bloated compared to Mac OS or Windows. In the present day, Windows and Mac OS X Quartz have internal subsystem separation similar to the client/server divide in X and comparable performance and resource usage to X with KDE or GNOME.
X에서 network이라는 단점은 unix domain socket을 사용함으로서 충분히 커버가 됩니다. 직접 하드웨어 가속을 이용하는 extension도 많기 때문에 X 자체는 performance bottleneck이 되지 않습니다.
제 생각에 directfb는 서버 클라이언트 코드 자체가 부담스럽고 그러한 transparency가 전혀 필요없는 임베디드 시스템에 어울린다고 생각합니다. 윈도우즈의 RDP와 같이 세션을 끊었다 연결하는 것이 가능하도록 개선하거나 하는 작업은 필요할 지 몰라도 그러한 가능성을 (거의?) 배제시켜버리는 directfb가 X의 대안이 되기는 힘들다고 봅니다.
오히려 요즘의 이슈는 GNOME과 같은 application에 있다고 봅니다. 물론 블랙박스보다 기능도 많고 덩치도 크니 그보단 느릴 수밖에 없죠. 하지만 이게 생각보다 더 느리고 생각보다 메모리를 더 차지한다는 데에 있습니다.
GNOME의 패널에서 시계를 보기 위해 메모리가 10M가 필요하다고 생각한다면 참 거시기하죠. 대부분의 패널 애플릿이 8-10M정도의 메모리를 차지합니다. 물론 VM이 아니고 RSS로요. 각종 서버가 사용하는 메모리 양과 비교해볼 때 너무나 많은 양을 차지하고 있습니다.
게다가 mozilla*, openoffice*, gnome*, (kde*)등이 제각각 라이브러리와 데이터를 로드하니 여기에서도 각종 메모리와 시간 낭비가 있구요. 예를 들어서 문자셋을 변환하는 루틴의 경우 glibc에 한 셋이 들어있고, mozilla에 한 셋이 들어있고, 아마 openoffice에도 한 셋이 들어있겠죠. (gnome은 glibc의 것을 이용하겠죠?) 툴킷도 mozilla따로 openoffice따로 gnome따로...
font rendering같은 경우도 freetype changes를 보니 계속 메모리쪽과 성능쪽 개선이 이루어지고 있는 거 같습니다.
이 외에도 전체적인 성는에 영향을 주는 요소는 너무나 많기 때문에 이런 것들을 종합적으로 생각하지 않고 X 의 network transparency를 victim으로 몰고가는 것은 좀 무리가 있는 듯 합니다.
관련 링크를 많이 찾지는 못했지만 다음 것들이 있습니다. (주로 GNOME의 최적화 필요성에 관련된 것입니다)
Re: X Window System어떠십니까?
벤치마크 결과가 어떤지 모르겠으나, X 윈도우가 MS윈도우보다 느리게 느껴지지 않고 성능 역시 뒤떨어진다고 생각되지 않습니다.
Mac OS X는 적어도 현재의 X 윈도우보다 느리게 느껴집니다.
user friendly한 입장에서는 맥 os X가 상당한 장점을 가지고 있으나, 어떤 GUI 시스템을 어떤 점에서 우수해야 좋은 것인지에 따라 달리 볼 수 있는 문제인듯 보입니다.
Re: X Window System어떠십니까?
제가 아는게 별로 없어서 X 문제인지 gtk 문제인지는 모르겠지만,
확실히 윈도우보다는 느리지 않습니까?
예를들어 python이나 자바같은 멀티 플랫폼 환경에서 같은 GUI 프로그램을
돌려보면 확실히 차이가 나잖아요.
음.. 물론, 최적화 문제일 수도 있겠군요.
----------------------------
May the F/OSS be with you..
Re: X Window System어떠십니까?
결국, 자바나 파이썬 문제와 같은 경우는 자바와 파이썬과의 더 밀접한 연관이 있지 않을까요?
멀티플랫폼이라고 하더라도, 자바 버츄얼 머신의 경우, 어차피 각각의 시스템에서 다른 성능을 보여주지 않나요? --;; 한편, 보통의 경우 다른 코드를 사용하는 프로그램들에 있어서 성능의 차이를 논하는것은 어려운듯 합니다.
p.s. 제게는 리눅스에서의 모질라가 확실히 윈도에서의 모질라보다 빨리 로딩이 되더군요.. --;; 그걸 가지고 엑스가 ms윈도우보다 성능이 좋다고만은 할 수 없겠지요.. -.-
Re: X Window System어떠십니까?
윈도는 다이렉트 렌더링 방식입니다. Win32 API 호출을 하면 윈도 GDI가 화면에 바로 뭔가를 그리죠. 반면 X는 클라이언트-서버 방식입니다. Xlib 호출을 하면 이게 X 프로토콜로 가공이 된 후 X 서버로 보내지고 X 서버는 다시 받은 X 프로토콜을 해석해서 화면에 뭔가를 그리게 됩니다. 당연히 X의 방식이 훨씬 느릴 수 밖에 없습니다. 느리게 느껴지지 않는다면 여러분의 CPU 파워가 강력하거나, 동시에 띄운 작업수가 많지 않아서 일 겁니다.
이 문제와 관련해서 최근 XFree86 프로젝트의 설립자중 한명인 David Wexelblat조차도 다음과 같이 이야기했습니다.
그밖에 UNIX Hater's Handbook "X 윈도우즈의 재앙" 부분을 읽어 보시면 X의 단점이 적나라(?)하게 기술되어 있으니 참고가 될 듯합니다.
X가 느린 것은 사실이라 생각합니다.윈도용 모질라와 리눅스용 모질
X가 느린 것은 사실이라 생각합니다.
윈도용 모질라와 리눅스용 모질라의 속도를 비교해 보면..
윈도용 모질라(저는 1.3 한글 버전을 씁니다)는 IE에 비해 엄청나게 빠르지요, 새창 뜨는 속도도 엄청 빠르고요. 스크롤 속도도 마찬가집니다.
하지만 리눅스용 모질라는 그렇게 빠르지 않습니다.
이것이 X와 win api의 차이인지는 확실히 말할 수는 없지만 제 생각엔 이걸로 충분하게 느낄 수 있다고 생각합니다.
rommance.net
-__- X윈도우..의
X윈도우는 MS 제품 보다 훨
느립미다..
사양이 올라가면 당연 빨라 져야지만..
하드웨어에 따라서는 별반 성능 향상이 없는 경우도
있습니다..
제컴퓨터.. 펜티엄 3 500Hz 190M 의 속도와..
펜티엄 4 2GHz 의 속도차가 많이 나지 않터군요..
둘다 프로그램 뜨는걸 기다려야 하니.. 원~~~ _-_
꼭 자바 같다는 생각이 들더군요..
게임쪽 상태는 더 안좋아지는것 같습미다..
아무래도 커널에 X윈도우를 옵션으로라도 넣어서.
속도를 올려쓰면 합니다..
============================================================
선한 인간이냐 악한 인간이냐는 그사람의 의지에 달렸다. -에픽테토스-
의지 노력 기다림은 성공의 주춧돌이다. -파스퇴르-
============================================================
http://xwin.org:9673/xwin/NetworkTranspa
http://xwin.org:9673/xwin/NetworkTransparencySlowdownMyth
X가 느린 건 비효율적인 xlib 때문이지, 네트웍 때문은 아니라네요.
Re: X Window System어떠십니까?
그런데 왜 제 컴퓨터에서는 Quake3, Unreal Tournament,
Return to Castle Wolfenstein등의 게임은 리눅스에서 더 좋은 성능을
보일까요?
제가 보기엔 각 응용 프로그램에 따라서 다른 것 같습니다. 이건 드라이버나
이런 것들의 질에 더 많은 영향을 받는 것 같습니다. X 프로토콜의 구조라기
보다는...
host xwindow server-client model
한 호스트 내에서 xwindow 의 서버와 클라이언트는 유닉스 socket address structure 로
AF_INET 류가 아니라서 속도가 빠르다는 말을 유닉스 네트워크프로그래밍에서
읽었습니다.
_________________
물론 AF_INET 가 리모트어세스에 사용되지만서도요.
하하하
어
Re: X Window System어떠십니까?
게임이 X위에서 도는건가요? 잘 모르지만, X위에서 도는게 아닐것 같은데요?
--
Life is short. damn short...
Re: X Window System어떠십니까?
그럼 Y 위에서 도나요? :-)
X 위에서 구동이 됩니다. X가 없으면 아예 실행도 안됩니다. 물론 콘솔에서
실행을 할 수도 있는 것들도 있습니다만 저는 X위에서의 구동을 가지고
비교를 한 것입니다.(제 노트북에서는 콘솔에서 하는 버전은 실행이 아예
안됩니다, 젠장...)
Re: X Window System어떠십니까?
MS 윈도우즈에서는 OpenGL을 직접처리하지 않고, Direct3D로 변형하여 처리합니다.리눅스는 그렇지 않죠. 그래서 더 빠른 것입니다.
Re: host xwindow server-client model
물론 유닉스 소켓은 AF_INET보다 빠릅니다.
그렇지만 메모리상에서 포인터로 데이터를 주고받고 하는 것보다
빠를 수는 없겠지요.
----------------------------
May the F/OSS be with you..
이젠 그런 자잘한 속도 논쟁보다는 얼마나 편하고 쓸만하느냐에 중점을 둬야
이젠 그런 자잘한 속도 논쟁보다는 얼마나 편하고 쓸만하느냐에 중점을 둬야 하지 않나 싶네요.
어차피 지금의 하드웨어 발전 속도라면야 조만간 그정도 속도야 충분히 뒤집고도 남습니다.
지금은 약간 비디오 렌더링 속도가 차이가 있긴 하지만.. 윈도처럼 직접 쓰나 뭐 중간에 잠시 거치나.. 씨퓨 속도가 3기가에 비디오 카드가 요즘 하이엔드급쯤 되도 유저가 그 속도차를 느낄수나 있을지요.
지금도 사실 왠만하면 그차이를 느끼는 사람은 드뭅니다. 그걸 따지고 드는 전문 개발자가 아닌한.. 안그런가요
여지껏 전 한번도 못느꼈습니다.
Re: X Window System어떠십니까?
OpenGL은 xlib를 거치지 않고 XAA/그래픽 드라이버와 바로 연결되니까 그렇지요. 대신 그 게임들은 다른 X 응용 프로그램과 달리 원격으로 실행 못합니다.
[quote="minsu"]이젠 그런 자잘한 속도 논쟁보다는 얼마나 편하
저도 그렇게 생각합니다. 이미 윈도우즈나 리눅스에서는 모질라가 느리다는 얘기가 거의 언급되지 않고 있는지 오래입니다. 그런데 시피유가 상대적으로 느린 매킨토시로 가면 다들 모질라가 느리다고 생각합니다.
엑스 윈도우 자체의 설계가 문제가 있다고는 하지만.... 이걸 버리고 새 플랫폼을 채택해야할만큼 나쁜 플랫폼인 것 같지는 않습니다.
오히려 최근의 리눅스 커뮤너티의 활동을 지켜보다보면 리눅스에서 엑스의 문제는 엑스 자체의 문제보다는 XFree86의 문제가 크지 않나 싶은데 다른 분들은 어떻게 생각하시는지요? Keith Packard가 프로젝트 forking까지 들고 나오면서 이 문제를 걸고 넘어진 것은 바람직한 일이라고 봅니다. 사실 지금도 리눅스를 까는데 걸리는 문제중의 하나가 XFree86에서 비디오 카드 셋업입니다. 리눅스의 역사가 이제 상당히 오래되어가고 있는데도 불구하고 이쪽이 아직까지 병목현상으로 작용하는 이유를 잘 모르겠습니다...
"I conduct to live,
I live to compose."
--- Gustav Mahler
근데 궁굼한데 로그아웃님은 요즘 뭐하십니까? 나우누리에서 뵙고 꾸준히 뵙
근데 궁굼한데 로그아웃님은 요즘 뭐하십니까? 나우누리에서 뵙고 꾸준히 뵙는군요. :D
[quote="minsu"]근데 궁굼한데 로그아웃님은 요즘 뭐하십니까?
주제와 관련이 없는 개인적인 내용은 이메일이나 개인 메시지 기능을 활용해 주시기 바랍니다....
Re: X Window System어떠십니까?
원격으로도 돌아가긴합니다. 하지만 원격으로 실행될 때는 x transport를 거치기 때문에 열라 느려지는거 같습니다. (하지만 원격으로도 하드웨어 가속은 가능한것 같습니다.)
참고로 아래는 XFree86에서 3d 가속을 사용할 때 쓰이는 dri가 어떤식으로 동작하는지에 대해 설명한 flow chart입니다.
http://dri.sourceforge.net/doc/images/control_flow_poster.jpg
nvidia드라이버는 이것과 다른방식으로 돌아간다고 알고있습니다만 glx 프로토콜은 호환된다고 합니다.(그러니 겜들도 돌아가겠죠)
----
데스크탑 프로그래머를 꿈꾸는 임베디드 삽질러
동영상도 신기하죠
X가 느린거같기는 한데...
이상하게 mplayer로 동영상을 플레이시켜보면...
느린것 같지가 않습니다.
윈도우보다 오히려 더 낫다는 생각도 들고..
신기합니다...
더욱이 코덱까지 다 있어서..전 요즘 동영상 볼때만 리눅스를 씁니다.-_-;;;;;
Re: X Window System어떠십니까?
잠깐 논의에서 벗어난 얘기 입니다.
이런 말은 처음 들었습니다. Windows 안에서의 OpenGL과 Direct3D의 작동
방식은 전혀 다릅니다. 위에 내열된 게임은 대부분 OpenGL로 구현되었으므로
Windows에서도 각 VGA 카드 드라이버 안의 OpenGL 드라이버에 의해 OpenGL 파이프라인을 따라서 작동 됩니다.
그리고 X 윈도우 시스템도 시대에 맞게 변화할 때가 되지 않았나 생각합니다.
유닉스,리눅스에서의 윈도우 시스템은 거의 XFree86의 독주였습니다.
이 부분에는 왜 다양성이 존재 하지 않는 것인지 모르겠습니다. 너무 큰
작업이라 그런지, 아니면 제가 모르고 있는것인지.
글쎄요...
전문가는 아니지만 속도차이는 확실히 많이 나더군요.
사실 AT를 쓰고 있을때 486급에서 dir를 눌러보고는 놀라서 자빠지는줄 알았죠. :-)
엄청난 속도차이가 보이더라는 겁니다. 그런데 이 486에 익숙해지니 펜티움이나오고
펜티움에서의 dir은 더욱 놀라웠지요.
요즘은 화면에 그려지는 선하나하나를 따지는 시대는 지나가서 전체적인 모습이 눈앞에
보일때 까지의 시간을가지고 속도를 평가하는 것으로 보입니다만 앞으로 더 많은
집적도의 IC들이 나오면 분명히 하드웨어의 속도차이는 분명히 보입니다.
주제가 X와 MS-Windows였군요...
X가 느리다고는 하지만 오래사용한 MS-Windows보다는 빠르다고 생각합니다.
시간이 지나면 지날수록 시작시에 무엇을 그리 많이 작업하는지 MS-Windows는 상당한
끈기를 요구하게 되더군요.
아직도 MS-Windows를 사용하고 있지만 5~6개월정도 사용하면 부팅될때의 속도가
부담이 되어서 옛날 허큘레스의 전설이 생각날 정도죠.(컴퓨터켜고 밥을 먹는다는...)
이건 분명 MS사에서 무언가 조치가 필요하다고 생각되는 단점중에 하나입니다.
데스크탑으로써 MS-Windows는 상당히 좋은 OS이지만 시간이 지나가면 지나갈 수록
나이가 먹는 OS는 별로 바람직하지 않다고 생각되어집니다.
물론 모든 물건이 시간이 지나면 재성능을 내지 못한다는것은 일반상식이지만
소프트웨어까지 그런 법칙을 적용시켜놓는다는건 안좋다고 생각됩니다. :(
X도 KDE나 GNOME과 같은 WM를 사용할때 엄청나게 느린것은 많은 수정이 되어야겠지만
그리 수정되어질것 같질 않군요.
아~ 지금위에 적은글은 사용상에 나타나는 현상이 아니라(약간은 포함되겠지만...) 부팅될때의
현상을 푸념해본겁니다. :D
------------------------------
좋은 하루 되세요.
저는 엑스역시 상당히 불안한 소프트라고 생각합니다. 흔히 윈도우를 비판할
저는 엑스역시 상당히 불안한 소프트라고 생각합니다. 흔히 윈도우를 비판할때 블루스크린을 많이들 얘기하는데 x도 작업내용을 돌려주지 않아서 멈춰버리는 경우가 곧잘 있습니다. 이런 경우 xkill이라는 강력한 해결책이 있긴 하지만 그조차도 안되는 경우에는 ctrl+alt+backspace로 아예 엑스윈도우를 종료시킨 후 재시작 하면 해결되기는 하지만 x위에서 돌아가고 있던 프로세스들은 단번에 종료되기 때문에 x윈도우를 기반으로 사용하는 저같은 사용자의 경우에 컴퓨터의 리셋버튼을 누르는 것과 다름없는 상황입니다. 오히려 2000이나 xp의 블루스크린보다 더 잦은 리셋을 하는 것 같습니다. ctrl+alt+del만큼이나 ctrl+alt+backspace키 조합이 손에 익을 정도니 말이죠
---
---
키체의 힘으로 당신에게 평안을...
Re: X Window System어떠십니까?
DirectFB가 있습니다.
그리고, directFB 사이트에 가보면,
directFB기반의 배포본 링크도 있습니다. :wink:
위의 어느 분께서 말씀하셨듯이, X가 느린 것이 문제라는 것은
어차피 하드웨어 성능이 더 향상되면, 언제가 사라질 화제라는 것에
동감합니다.
그리고, X의 C/S 구조를 활용하는 일이 적어서
지금은 돼지의 진주처럼 여겨질 뿐이지,
만약 이것이 보편화가 된다면,
어쩌면
cygwin에 느리게 돌아가는 X서버를 투정하거나,
혹은 상용소프트웨어에 돈을 지불하거나 하며,
M$를 욕하면서,이 구조에 감사하게 될 일도 생길 수 있습니다.
There is no spoon. Neo from the Matrix 1999.
Re: X Window System어떠십니까?
X-window 시스템에 만족하고 있지만, directFB 도 꽤 흥미롭네요.
ByzantineOS : http://byzgl.sourceforge.net/
directFB 로 LiveCD 를 만들면 지금보다 더 thin 해질수 있을려나!!
개인적으로 몇번 써 본 경험에도 X는 불안정하고 윈도보다 느린구석이 있습
개인적으로 몇번 써 본 경험에도 X는 불안정하고 윈도보다 느린구석이 있습니다. :( (이젠 Ctrl+Alt+Backspace 누르기 싫어요~)
하드웨어의 발전으로 언젠가는 사라지겠지만, 컴퓨터를 계속 주기적으로 업그레이드하는사람은 오히려 흔치 않습니다. 하드코어게이머나 IT관련 종사자의 경우 컴퓨터를 주기적으로 업그레이드해서, 시대에 발맞춰 컴퓨터를 개조해나가지만 일반 라이트 유저의 경우 이미 골동품이 된 컴퓨터를 4년~5년 써오고 있습니다. 펜II 유저도 아직 많고요. 펜3 캣마이 유저는 더 많습니다.
X의 서버-클라이언트방식은 확실히 장점이 많지만서도 라이트 유저를 위한 다른 체제 하나쯤은 있어도 좋을것도 같습니다.
───────────────────────
yaourt -S gothick elegant
khris'log
[quote="khris"]개인적으로 몇번 써 본 경험에도 X는 불안정하
제 생각에 X를 불안하게 만드는 가장 큰 원인은
불완전한 드라이버 문제가 가장 큰 것 같습니다.
X가 지원이 잘되는 그래픽 카드 사용자인 저는
X서버 리셋이 ctrl+alt+backspace라는 것을
기억을 못해낼 정도로 리셋을 누르는 것이 드믑니다.
참고로 저는 매트록스 사용자입니다.
Fedora Core 3 출시 하자마자 설치하고 나서
크래쉬가 아니라 한글관련 설정을 다시 불러오기 위해 한번 누르것 외에는
단 한차례도 없었습니다.
실제로 그 때 키가 기억이 안나서
Ctrl+alt+누머릭패드의 플러스 키를 누르고 리셋이 된 걸로
오해해서, 한참 삽질을 했었죠...
(그 전에 레드헷7.2를 사용했는데 X서버가 크래쉬해서
ctrl+alt+backspace를 눌렀던 기억이 거의 없습니다.)
이러한 문제는 X의 근본적인 문제보다는
부족한 써드파티나 메이저 밴더들의 지원에 기인하고
있을 가능성이 높습니다.
하나쯤이 아니라 꽤 많습니다.
위의 언급되어진 DirectFB만 아니라..
임베디드 시스템을 위한 QT기반의 GUI도 있는 것로 알고 있습니다.
There is no spoon. Neo from the Matrix 1999.
DirectFB 는 하드웨어 편향성이 좀 문제가 됩니다
DirectFB 는 하드웨어 편향성이 좀 문제가 됩니다.
현재 Matrox G400 정도만 거의 100% 가깝게 기능이 지원되고, 나머지 카드들은 그 기능을 거의 활용하지 못합니다. G400 유저 입장에서는 반가운 일이긴 하지만, 지원되는 하드웨어의 숫자가 적다는 것은 그만큼 개발자 및 사용자층을 제약하는 결과를 가져옵니다.
이런저런 시도는 많지만 당분간은 X 의 범주를 벗어나기는 어려울 것으로 보이네요.
DirectFB 로 X 를 띄울려면 XDirectFB 라는 레이어가 필요
DirectFB 로 X 를 띄울려면 XDirectFB 라는 레이어가 필요합니다.
XFree 나 Xorg 의 소스에 패치를 해서 DirectFB 위에 X 를 띄웁니다.
그런데 저 XDirectFB 라는 프로젝트가 2년넘게 진척이 없거든요.
개발자가 손을 떼 버린건지... :?
보아하니 DirectFB 도 기존 PC에서 구현보다는 하드웨어자원이 부족한 임베디드시스템에서의 활용쪽으로
방향을 바꾸는 것 같습니다.
찾아보니 X 의 대안이 되지는 못하겠지만 새로운 X 에 대한 시도들이 있네요.
The Y-Windows System
The KDrive Tiny X Server
----------------------------------------
Nothing left after Nirvana.
[quote="웃는 남자"]찾아보니 X 의 대안이 되지는 못하겠지만
현재 Kdrive는 XServer라는 이름으로 Freedesktop 쪽에서 작업하고 있습니다.
최근 몇몇 리눅스 배포판(Novell Ximian, Fedora/RedHat)쪽에서 Xserver를 기반으로 하는 아래의 프로젝트를 이용해서 차기(?) 데스크탑 환경을 준비중입니다.
http://freedesktop.org/wiki/Software_2fXgl
http://freedesktop.org/wiki/Software_2fXephyr
[quote="luark"]저는 엑스역시 상당히 불안한 소프트라고 생각합
저는 이 의견에 반대입니다. luark 님이 그러하시다면
그것은 X 자체 문제가 아닐것입니다. 왜냐면 전 그놈 데스크탑으로 작업은 주로 코딩작업과 영화, 음악을 듣는데 업타임 한달씩 쓰기
때문입니다.
http://xcb.freedesktop.org/wiki/X쪽도
http://xcb.freedesktop.org/wiki/
X쪽도 놀고만 있지는 않습니다 :)
오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...
http://mytears.org ~(~_~)~
나 한줄기 바람처럼..
오픈쥐엘을 다이렉트 엑스로 싸서 돌린다는 이야기는, 비스타 버젼에서 나온
오픈쥐엘을 다이렉트 엑스로 싸서 돌린다는 이야기는, 비스타 버젼에서 나온 이야기 같구요,
http://bbs.kldp.org/viewtopic.php?t=54447&highlight=directfb
이 글타래를 보고 directFB가 꽤나 분발하고 있다고 생각했는데,
오래된 영상들이었나요....
그런데 제가 아직 개념이 잘 안서서 그러는데,
directFB는 말 그대로 프레임 버퍼죠. 그런데 프레임 버퍼가 뭔가요?
텍스트 이상의 그래픽을 그려주는 레이어인가요?
그럼 엑스 윈도우 없이, 프레임 버퍼랑, 데스크탑시스템류(그놈이나 kde) 같은걸
엮을 수 있나요?
그놈이나 kde는 데스크탑 시스템이라면, xfce4같은건 윈도우시스템인가요?
너무 무식해서 모르겠군요...
만일 프레임버퍼로 엑스없이 윈도우시스템을 돌릴 수 있다면, 이전에 제공되던
다른 프로그램들... 엑스 라이브러리를 사용하지 않았다면, 그 프로그램들도
다 돌릴 수 있는 건가요?
엑스를 벗어난 리눅스 윈도우 시스템을 만들면, 기존의 프로그램들을
새로 다 포팅해야하는 건가요? (서버/클라이언트 기능을 제외하려면)
글타래 하나는 잘못 올라와서 지웠습니다.
프레임버퍼는 하드웨어에 대한 제어를 추상화해놓은 것이라고 보면 됩니다.
프레임버퍼는 하드웨어에 대한 제어를 추상화해놓은 것이라고 보면 됩니다.
하드웨어를 직접 제어하는 것 보다 편하게 하기 위해서 미리 함수를 만들어 놓는 거죠.
예를 들어 사각형그리기는 DrawRect(), 노란색 채우기 FillYellow() .... 등등 이런식으로요.
물론 프레임버퍼위에 작동하기 위해서 코드를 새로 작성해야 됩니다.
XDirectFB 는 DirectFB 상에서 X 를 구동하기 때문에 Gnome,KDE,fluxbox 등 모두
다 쓸수 있습니다. XDirectFB 는 실시간 알파채널랜더링이 되어서 모든 창이 투명하게 되는데
이게 정말 뽀대(?)가 나죠.
그리고 DirectFB 를 쓸때 장점은 굳이 X 를 띄우지 않아도 여러가지를 할수 있는게 좋습니다.
mplayer 의 dfbmga 드라이버로 TV출력,
콘솔에 만화보기 DFBSee,
로그인매니저 Qingy,
XML 형식 프리젠테이션 DFBPoint,
links 의 direcffb 드라이버로 웹브라우징,
directfb 드라이버를 지원하는 게임라이브러리 clanlib 을 사용하는 게임 ex. clanbomber (크레이지아케이드 같은거)
등등..
----------------------------------------
Nothing left after Nirvana.
[quote="luark"]저는 엑스역시 상당히 불안한 소프트라고 생각합
제 경우에는 파폭이 문제입니다. 데비안 testing 버전을 쓰고 있는데 배포판의
파폭이 램을 스왑까지 99% 먹어버리곤 리ㅤㅅㅔㅌ을 해야하는 경우로 치닫습니다.
10분을 기다리고 20분을 기다려도 하드 스왑으로 인한 디스크 액세스만 끝없이
계속 하더군요.
또 루x웹 이니 하는 특정 게시판에서 메모리 점유율이 악몽과도 같이 올라가서
상당히 반응 속도가 처지는 것을 매일 같이 경험합니다. 윈도즈에서의 파폭의
높은 메모리 점유율을 토로하는 유저의 글이 가끔 올라오는 걸 보면 이 부분은
개선의 여지가 있는 듯 싶습니다.
파폭 말고는 엑스 윈도 자체는 괜찮은 듯 싶더군요. 루크옹은 어떤 넘이 말썽을
부리시는 건지 알고 싶군요. :D
믓흥..
이래서 kldp매니아들이 되어가는가봅니다..
아무생각없이 들어와보니 재미있는 주제가 있군요..(사실은 제가 방옹 빠돌이)
X-windows의 속도나 그런것들을 문제삼으시는 분들도 있는데...
몇가지 나름대로의 전제를 세우고 시작해보겠습니다.
1. X-windows는 충분히 빠르다
2. 현재시점에서야말로 X-windows의 network model은 충분히 유용하다.
3. X-windows가 불안한 이유는 과연 무엇인가?
이 세가지에 대해 나름대로 얘기를 해보겠습니다.
1. X-windows는 충분히 빠르다.
무겁다고 생각되는건 gnome이나 kde를 사용해서 벌어지는 일이 대부분이라는게 제 생각입니다. 물론 저도 gnome을 사용하기는 합니다만... 무겁습니다. gnome이 windows보다 무거운건 맞습니다만... X-windows자체가 무거운건 아닙니다. 특히 opengl 하드웨어가속은 ms-windows보다 더 빠르다고 생각됩니다.
2. X-windows의 network model
이것은 대단히 중요한 의미를 가집니다. 물론 어떤 분들은 전혀 쓸모없는거라 말씀을 하시기도 합니다만... 하드웨어 리소스가 제한될수록 더더욱 진가를 발휘합니다. 아무리 뒤떨어진 OS라도 X-windows server만 있으면 linux에서 최신의 application들을 땡겨와서 사용할 수 있습니다. 그것도 linux가 돌아가고 있는 컴퓨터의 사용이 좋으면 좋을수록 더 빠른 반응을 얻을 수 있습니다. 물론 구조적인 문제점이 전혀 없다고 하면 거짓말일 수도 있겠습니다만.. 최소한 windows의 RDP보다는 훨씬 좋은놈이라 생각합니다. (하긴.. rdp는 사운드가 나오니깐... RDP가 더 좋을라나요...?)
3. X-windows가 불안정하게 생각되는 이유
X-windows는 기본적으로 대단히 안정적인 시스템이라 과히 자부합니다. 문제가 있는 경우는 이미 다른분들이 말씀하셨지만 굳이 정리하자면 다음과 같습니다.
1) X-windows상에서 작동되는 어플리케이션의 불안정함
2) 하드웨어의 불안정함
3) Driver등의 불안정함
난데없이 웬 하드웨어가 등장하는것인가.... 라는 분들이 계실텐데.. 제 경험상 linux는 windows보다 하드웨어상태에 더 민감한 OS라고 생각됩니다. LFS부터 빌드를 하거나 젠투를 stage1부터 빌드를 해보면 더 극명히 드러나는데.. 제 경우는 이런 불안정성때문에 하드웨어를 바꾸면 항상 테스트를 해보는 편입니다.
application은 말할것도 없고 firefox가 cpu를 많이 먹으면서 뻗는건 대개 plugin의 문제입니다. 제 경험으로는 초기에는 mplayerplug-in이 문제였었고 요즘은 flash plugin이 여러 tab을 열면 cpu를 많이 드시면서 저승으로 가십니다.
driver의 불안정함은.. 아마 다들 아실겁니다. 그나마 잘 제공되는 nvidia driver마저도 버전에 따른 차이를 보입니다.. 무서워서 최선버전은 잘 못쓰는 편이거든요....-.-;
4. 기타사항
x-windows의 대안품들은 예전부터 있었습니다. 지금이야 아예 이름이 바뀌어서 다른쪽에서 사용되고 있지만.. 원래 berlin이라는 프로젝트가 있었죠. 현재는 BeOS의 clone인 HAIKU의 display 엔진으로 사용되고 있는걸로 알고있습니다. directfb보다 훨씬 먼저 나왔던 X-windows의 대안이었습니다.
뭐 이런논의가 항상 그랬듯이.. 플레임성의 위험을 가지고 있는건 사실입니다. 정보와 의견으로 좋은 토론이 되었으면 합니다.
ps. 방옹....배고파요..
-----새벽녘의 흡혈양파-----
엑스윈도우즈는 현재도 충분히 빠르다고 생각합니다.현재 윈도우즈 상에서
엑스윈도우즈는 현재도 충분히 빠르다고 생각합니다.
현재 윈도우즈 상에서 아무것도 띄워 놓지 않은 상태에서 돌려도 그놈 환경이라도 확실히 빠르게 느껴집니다.파폭 구동속도도 윈도우즈의 그것 보다 훨씬 빠른 편입니다.다만 문제라면 제대로된 그래픽 가속을 지원해주는 드라이버가 많이 존재하지 않는 다는게 문제가 아닐까요...?
인생이란게 다 그런게 아니겠어요....? 뭘(?)
http://schutepen.egloos.com
저도 드라이버 문제라고 생각합니다.유져가 적어서 시장성이 없다고
저도 드라이버 문제라고 생각합니다.
유져가 적어서 시장성이 없다고 생각하는지...
그나마 nvidia는 괜찮은 녀석입니다.
ati의 드라이버를 써보신 분은 다들 공감하시리라고 생각합니다.
윈도 드라이버의 80%만큼만 신경 좀 써줘도 ;
[quote="ㅡ_ㅡ+"] 루크옹은 어떤 넘이 말썽을부리시는 건지
최근 쓰는 프로그램 중에서는 totem이 가장 말썽을 부리더군요. 종료시키면 화면이 먹통이 되면서 소리는 계속나는 난감함.. 다른 가상데스크탑으로 이동해서 터미널 띄운 후 killall totem으로 해서 해결하곤 합니다만..; 처음에는 무작스럽게 엑스리셋을 시키곤 했었죠.;(저 글 쓸 당시;;)
---
---
키체의 힘으로 당신에게 평안을...
주제에서 좀 벗어났지만, 확실히 해둘 필요가 있을 것 같네요.출처
주제에서 좀 벗어났지만, 확실히 해둘 필요가 있을 것 같네요.
출처: http://en.wikipedia.org/wiki/X_Window_System
Nomenclature
"X Window System" is commonly shortened to "X11" or simply "X". The term "X Windows" (in the manner of "Microsoft Windows") is officially deprecated and generally considered incorrect, though it has been in common use since the inception of X and has been used deliberately for literary effect, for example in the Unix-Haters Handbook.
그리고, 제가 보았던 맞춤법에서는 '윈도우'가 아니라 '윈도'를 옳은 표기라고 했는데, 맞춤법이 자주 바뀌어서 요즘은 모르겠네요. 자세히 아시는 분이 고쳐 주셨으면 좋겠습니다.
Re: 믓흥..
arts 나 esd 를 쓰면 소리도 나올텐데요 ;)
(역시 oss 나 alsa 아니면 즐이려나;; )
오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...
http://mytears.org ~(~_~)~
나 한줄기 바람처럼..
[quote="다크슈테펜"]엑스윈도우즈는 현재도 충분히 빠르다고 생각합니
현재 DRI프로젝트에서는 다음의 비디오 카드들에 대한 하드웨어 가속(3d)이 지원되네요.
3dfx Banshee/Voodoo3, 4, 5
ATI Mach64 (Rage Pro)
ATI Rage 128 (Standard, Pro, Mobility)
ATI Radeons up to 9200 are supported
Intel 810, i810-dc100, i810e, i810e2, i815, i815e, i830, i845, i852/855, i865, i915
Matrox g200/g400/g450/g550
S3 Savage3D, SavageMX/IX, Savage4, Supersavage, Prosavage/Twister/DDR
SiS 300/305, 540, 630/730
Via CLE266, Castlerock, Unichrome, ProSavage-DDR400
----
데스크탑 프로그래머를 꿈꾸는 임베디드 삽질러
X의 network model은 제게는 정말 유용합니다.전 R의 통계
X의 network model은 제게는 정말 유용합니다.
전 R의 통계패키지를 이용해서 plot을 많이 그립니다.
메모리가 많이 필요하기 때문에 IBM 64bit 서버의 8G 메모리를 써야 합니다.
윈도우에 Xmanager란 Xserver프로그램을 설치하구요. 터미널로 접속해서 코드를 입력하면 윈도우에 그림창이 뜹니다. 계산은 서버에서 보는건 개인pc에서 첨엔 넘 신기하더라구요. 옛날에 어떻게 이렇게 시스템 디자인할 생각을 했는지..^^ firefox도 (사실 전 opera를 선호합니다.) 서버의 application을 윈도우에 띄워서 사용합니다. 이렇게 하니 개인pc에 linux를 설치할 일이 정말 없더군요. 딱 한가지 아쉬운 거는 이런 구조면 터미널의 screen 같은게 가능할 것 같은데 (X의 작업을 저장했다. 나중에 다른 곳에서 접속해서 보는) 못 찾겠더라구요. 이것만 되면 최상의 작업환경인데...
...
arts는 몰라도 esd는 낭패.. 하지만 gst가 있으니 기대해볼법도..(틀렷)
-----새벽녘의 흡혈양파-----
PC에 X 서버를 깔아놓고 외부의 프로그램 화면을 볼 때에 RENDER
PC에 X 서버를 깔아놓고 외부의 프로그램 화면을 볼 때에 RENDER extension이 필요한 경우가 있습니다. 요즈음 데스크탑 환경의 프로그램은 대부분 RENDER extension이 필요하죠.
이 경우에 이 extension이 없는 X 서버를 사용하면 보이긴 하지만 무지하게 느립니다. 저번에 사용해본 바로 Xmanager는 RENDER extension이 없는 듯 하더군요. Xmanager로 딴 컴퓨터의 GNOME session을 통째로 띄워본 일이 있었는데 (테스트로...) 무지하게 느려서 사용할 수가 없었습니다. 그런데 cygwin X는 나름 쓸만한 속도가 나오더군요. cygwin X는 RENDER extension을 지원합니다.
속도 차이가 장난이 아니니 혹시 원격으로 띄울때 속도때문에 좌절한 분은 이 문제가 아니었나 고려해 봄직도 하네요 ^^ 그렇다고 GNOME session을 통째로 띄워서 사용할 정도는 아직 아니구요. 프로그램 하나 둘 띄워 쓰는데는 큰 불편함이 없습니다.
X에서도 windows의 remote desktop처럼 최적화된 원격 접속 기능이 있었으면 정말 좋겠네요 :)
[quote="ganadist"][quote="다크슈테펜"]엑스윈도우즈는
ATI그래픽 카드 사용자는 확실히 이부분에서 공감하실것 같구요.
우선 그들이 말하는 flgrx의 적용 범위가 적다는 것입니다.엔비디아는 모르겠지만 ATI는 모바일계열은 하이엔드 그래픽 사용자를 제외한 구형 노트북 사용자들은 ATI드라이버로 지원되지 않을 뿐더러 지원할 생각도 없는 것 같습니다.오픈지엘로 돌린다고 해도 분명 제 노트북은 툭스레이서 정도는 돌릴 사양입니다.HP 사이트가면 드라이버 찾아봐도 운영체제는 2000 그리고 엑스피(이 드라이버로 설치하면 2003에서도 가속이 됩니다. :D ) 에서 구동되는 드라이버가 전부이고 리눅스 드라이버는 찾아 볼수도 없습니다.엔비디아가 장착되어 있는 데탑 두곳에서는 네버윈터 나이츠도 즐기고 하는데 노트북에서는 절망뿐입니다.웹사이트 우분투 포럼 드라이버를 찾아 다녔지만(여기도 질문 두번이나 올렸지만 답변은 없었습니다.) 역시 절망이더군요..
그리고 설치도 그렇게 용이한편도 아닙니다.엔비디아의 그래픽 드라이버는 약간의 불편(윈도우즈버전보다는 불편한면이)이 있지만 쉽게 설치하고 업데이트도 용이하고 쉽게 세팅하고 잘 사용할수 있지만 ATI드라이버는 섬세하기도 하거니와 또한 설치도 용이하지 않습니다.
지원된다는 의미에서는 ATI가 들어갈지도 모르지만 잘사용하기에는 몇몇 하드웨어 엑스윈 서버를 제외하고 글러먹은 드라이버가 ATI입니다.
PS:현재 노트북에 특이한 하드웨어 두개가 장착되어 있습니다.하나는 MD고 두번째는 ACECAD II 시리얼버전입니다.이두개는 하드웨어 문제없이 리눅스 상에서 돌아갑니다.엠디는 장착하자 마자 쓰기 읽기가 가능했고(하이엠디라서 일반 데이터도 엠디에 저장이 가능합니다) ACECAD II는 삽질은 조금 했지만 지금은 잘 사용할수 있습니다만 ATI 그래픽 카드는 삽질을 해봐도 나아지는 기색이 없습니다. :cry:
인생이란게 다 그런게 아니겠어요....? 뭘(?)
http://schutepen.egloos.com
저도 X가 아니라 KDE, GNOME이 느리다는 생각을 합니다. 가벼운
저도 X가 아니라 KDE, GNOME이 느리다는 생각을 합니다. 가벼운 윈도우 매니저를 쓸 때는 체감 속도가 윈도우보다 빠르거든요. KDE, GNOME도 영문으로 쓸 때는 윈도우보다 빠를 때가 있습니다. 한글 폰토의 랜더링 속도에 문제가 있지 않나 하는 생각도 좀 해봅니다.
근데 웬지 리눅스 데스크탑으로 오래 작업하면 윈도우할 때보다 눈이 더 아픕니다. 그런 거 느끼신 분 없나요? 폰트를 꽤 여러 가지로 바꿔보고 윈도우 TTF 끌어와서도 써보고 했는데 뭔가 좀 이상하네요. 리프레시 레이트도 조정해봤는데 이게 조정이 되는 건지 아닌지 잘 모르겠더라는-_- 이런 거 느끼신 분들 어떻게 해결하고 있으신지 궁금하네요.
[quote="satyrs"]X의 network model은 제게는 정말
VNC 쓰세요. 작업하다가 접속중단하고 딴곳에서 다시 그화면 그대로 접속할 수 있습니다. 물론 어플은 고대로 돌고 있지요.
No Pain, No Gain.
[quote="fibonacci"]VNC 쓰세요. 작업하다가 접속중단하고
VNC가 X보다는 약간 느리다는 느낌이 들더군요...
섬세한 작업을 하기에는 VNC는 그 반응 속도에서 약간 어렵지 않나 생각이 듭니다.
There is no spoon. Neo from the Matrix 1999.
[quote="creativeidler"]근데 웬지 리눅스 데스크탑으로
테마 색상에 원인이 있지 않을까요? 남는 것은 그것 뿐이네요...
There is no spoon. Neo from the Matrix 1999.
저는 개인적으로 X는 정말 문제가 많다고 생각합니다. X의 문제인지, X
저는 개인적으로 X는 정말 문제가 많다고 생각합니다. X의 문제인지, XFree86의 문제인지, 아니면 윈도우 매니저의 문제인지, 어플리케이션의 문제인지, 드라이버의 문제인지는 잘 모르겠습니다만... 어쨌거나 X가 기본 구조 상 상당한 오버헤드를 가지고 있다는 걸 부정할 수는 없다고 봅니다. 장점도 많지만 말입니다.
그런데 X를 옹호하는 쓰레드를 다는 분들의 논리는 수긍하기 어렵습니다. X가 오버헤드가 많은 건 사실이지만, 하드웨어 성능이 좋아지고 있으니까 문제가 안 된다... 만약 M$에서 그렇게 말했다면, 아마 여기 게시판에 불이 나겠지요. 거봐라, 실력이 안되니까 별 해괴한 핑계를 다 댄다, 꼭 최신 사양으로 컴을 꾸미라는 법 있냐...
그렇게 말한다면, X의 약점이자 강점인 C/S 구조도 더 이상 강점이 아닙니다. M$도 개념은 다르지만 리모트 터미널 기능이 있습니다. 훨씬 무겁습니다. 하지만 뭐가 문제랍니까? 하드웨어 좋은 걸 쓰면 되는데... 기가비트 랜카드도 2, 3만원 밖에 안 하는데...
X가 효율적이냐 아니냐 느리냐 안 느리냐 라는 점보다, 유저 데스크탑 환경이라는 좀더 큰 틀에서 문제를 봐야 하지 않겠습니까? 사용자 편의성, 속도, 안정성, 한글 입출력(이거 정말 불만 많습니다), 시각적인 만족감, 다양한 어플리케이션의 지원, 어플리케이션의 안정성, 비용(금전적인 면과 시간적인 면 모두)....
(이렇게 말하면 플레임이 될 지도 모르겠습니다만) 리눅스가 언제까지 구루들의 장난감으로 자족한다면 구태여 이런 말 하는게 무의미 하겠지만 말입니다.
아직 멀쩡히 살아있는데 死因은 무슨....
[quote="snoman"]저는 개인적으로 X는 정말 문제가 많다고 생
위에도 잠깐 나왔지만 우선 저나 몇몇 다른 분들이 모두 'X가 기본 구조상 오버헤드가 크다'라는 전제를 snoman님과 같이 당연하게 받아들이고 있지 않다는 점을 주목해 주시기 바랍니다. 저도 그 부분에 대한 설득력 있는 근거가 있다면 알고 싶습니다만, 그런 근거가 없기 때문에 저런 전제를 받아들이지 못한다고 해서 모두가 snoman님께서 말씀하시는 것처럼 '억지'를 쓴다고 볼 수는 없다고 생각합니다.
윗분께서도 지적하셨 듯이 단순히 같은 사양 컴퓨터에 리눅스를 깔면 GUI 반응이 윈도우즈보다 못한 것 같다는 느낌 만으로 그걸 X의 구조적 문제 때문으로 단정할 수 없습니다.
글꼴 처리 방식, 데스크탑 환경의 구현 문제, 사용한 그래픽 드라이버의 수준 등등 수 많은 변수가 있기 때문에 그런 주장을 위해서는 보다 객관적이고 검증 가능한 근거가 필요하다고 봅니다.
----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...
fender님, 오버헤드의 정의가 다시 필요한 건 아니겠지요? 그런 의미
fender님, 오버헤드의 정의가 다시 필요한 건 아니겠지요? 그런 의미로 쓰신 건 결코 아닐 거라고 생각합니다. 다이렉트 렌더링 이야기가 왜 나왔는지 모르는 분도 아닐 테니 그 얘길 반복할 필요도 없구요. x 개발자 내부에서도 오래 전부터 이야기되어 왔던 부분입니다.
오히려, 오버헤드가 크지 않다고 생각하시는 분들이 오버헤드가 크다는 주장에 반론을 제시하셔야 하는 게 아닐까요? "보다 객관적이고 검증 가능한 근거"를 가지고서요.
아직 멀쩡히 살아있는데 死因은 무슨....
[quote="snoman"]fender님, 오버헤드의 정의가 다시 필요
계층이 늘어나면 '오버헤드'가 생긴다는 건 상식적입니다만, 그게 '상당한 오버헤드'가 될는지는 데이터가 없으면 알 수 없습니다.
여기서 말하는 '상당한'은 구체적으로 동일한 조건 하에서 동일한 GUI 응용 프로그램을 구동했을 때 사용자가 불편함을 느낄 수 있을 만큼의 속도 저하가 있는 것으로 가정해야 할 것입니다. 또한 안정성 문제도 나왔으니 성능 이외에 그런 계층의 추가로 인해 혹시 사용자가 느낄 수 있는 정도로 동일한 응용프로그램이 자주 오동작을 하거나 죽는 경우가 발생하는 경우를 말합니다.
이렇게 봤을 때 윈도우즈와 리눅스 등의 X윈도우 시스템 간의 오버헤드를 일반 사용자가 체감하는 건 사실상 어렵습니다. 왜냐하면 일단 '동일한 조건'이라는 것 자체를 충족하려면 예를들어 단순히 윈도우즈에서 모질라 더블 클릭해보고 그놈에서 클릭해보는 수준으로 판단 가능하지 않기 때문입니다.
같은 응용프로그램이라도 윈도우즈와 그놈/KDE 간에 사용한 비디오 카드 드라이버의 성능/안정성이 다를 수도 있고 글꼴 처리 방식이 다를 수도 있습니다. 반면 저 같은 경우는 오히려 예를들어 3D 크로스 플랫폼 게임을 양쪽에서 돌려 보거나 동영상을 재생해 보아도 별다른 FPS 차이를 느끼지 못하겠더군요.
한 가지 오해를 없애기 위해 말씀드리자면 이 문제에 대해 저는 snoman님이나 다른 분들 이상으로 아는 바가 없습니다. 다만 이제까지 "윈도우즈가 리눅스보다 GUI 성능이 월등하다"라던가 그 이유가 구체적으로 'X 윈도우가 네트워크 기반 설계를 채택했기 때문'임을 입증할 설득력 있는 근거를 본적이 없을 뿐입니다.
오히려 위에도 링크가 있지만 왜 네트워크 기반이라 느리다는 것이 근거없는 'myth'인지에 대한 이야기는 본적이 있습니다.
다시 말씀드리면 이 문제에 대해 제가 원하는 건 무조건 X윈도우가 좋다는 걸 인정시키는게 아니라 단지 '내가 써보니까 윈도우즈가 훨씬 빠르더라', 아니면 '네트워크 거치면 당연히 느린거 아니냐?'하는 이상의 어떤 설득력 있는 근거입니다.
----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...
fender님,오버헤드와 안정성은 일단 별개의 문제인 것 같습니다
fender님,
오버헤드와 안정성은 일단 별개의 문제인 것 같습니다. 제 생각에 오버헤드는 크게 두 가지를 들 수 있다고 생각합니다. 성능의 저하와 리소스(메모리, CPU ...) 점유율입니다. (물론 개발이나 유지보수의 오버헤드도 있습니다만, 개발자가 아닌 이상 상관 없으니 패스)
X 윈도우가 네트워크 기반이지만 빠르다는 건 unix domain socket이 tcp socket과 비교해서 빠르다는 거지, 다이렉트 렌더링보다 빠르다는 건 아닙니다.
예전에 단순히 Hello, world를 출력하는 프로그램을 QT로 만들어서 M$ 윈도우와 X에서 컴파일해서 돌려봤습니다. 메모리 점유율은 M$ 윈도우의 경우 8MB 정도, X는 16~17MB 정도였습니다. X 자체의 문제인지, solaris의 문제인지, xlib의 문제인지, QT의 문제인지는 모르겠습니다.
그리고 설득력 있는 근거는 xfree86 개발자 포럼에 이미 올라와 있습니다. 궁금하시면 참고하시길....
아직 멀쩡히 살아있는데 死因은 무슨....
[quote="snoman"]X 윈도우가 네트워크 기반이지만 빠르다는 건
그게 '얼마나' 빠른지가 문제 아닐까요? 흔히 하는 이야기로 예를들어 A라는 언어가 B라는 언어보다 GUI에서 10배가 빠르다면 엄청난 것 같지만 그 결과가 만약 버튼을 눌렀을 때 결과가 나오는 시간이 A 기반 응용프로그램은 0.001초, B가 0.01초라면 일반 사용자 입장에선 전혀 의미가 없습니다. 둘 다 '충분히 빠른' 결과이기 때문입니다.
만약 GUI 반응속도에서 현저한 차이가 난다면 그건 최소한 0.05초 대 1-2초 정도가 되어야 의미가 있는 것입니다. 그리고 이 논의에서는 단순히 domain socket을 쓰는 것보다 다이렉트 렌더링이 빠르다는 것보다는 과연 그 속도 차이가 실제 사용자에게 느껴질 정도로 큰 것인지가 중요하지 않나 싶습니다.
글쎄요... 저도 모르겠군요 :) 다만 그게 처음 말씀하셨던 'X윈도우의 구조적인 문제점'을 증명하는 근거가 될 것 같지는 않습니다.
이 부분은 저도 무척 궁금합니다. 혹시 바쁘지 않으시면 링크라도 뿌려주시면 저나 다른 분들에게 도움이 될 것 같습니다.
----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...
그냥 보이기에 M$윈도그와 X의 성능자체는 M$윈도그가 좋지 않습니까.
그냥 보이기에 M$윈도그와 X의 성능자체는 M$윈도그가 좋지 않습니까.
최대한 비슷한 환경을 꾸민다는 가정하에서 말입니다.
'플렉스박스정도 하나 뛰어 놓고 윈도우보다 속도가 빠르다.'라고 말하는 것은 억지로 밖에 보이지 않습니다.
그리고 C/S환경의 경우엔 이건 정말 어려워졌습니다. 현재의 X는 초기와는 다르게 돌아가고 있으니까요. 마치 윈도우 3.1에서 윈도우 95 혹은 98이 된 거처럼 하드웨어를 직접 접근하는 방식을 사용하게 됨으로서 성능 향상이 많이 되었고 윈도그와 개별적으로 비교할 경우엔 성능이 뛰어난 부분도 존재한다고 생각됩니다.
(얼마 전에 설치활용쪽에도 비슷한 쓰레드를 남겨서 X의 성능을 향상하는 방법에 대해서 알게 되었습니다. Gtk나 QT를 directFB계열로 돌리면 비약적인 퍼포먼스의 향상을 불러 올 수도 있겠더군요. 아직 시험해 보지는 않았습니다.)
fender님의 말씀처럼. X나 윈도그는 여러 프로그램들의 혼합이기 때문에 X자체의 구조를 따져서는 안 될 것 같기는 합니다. 그렇다고 해도 전체적인 성능은 떨어집니다.(위에 언급한 가정하에서 말이죠.) 이 눈에 보이는 차이 때문에 윈도그와 X의 확연한 차이점인 C/S구조가 문제가 아니냐고 생각하게 되는 것이죠.
그러나 사실 그럴 수밖에 없는 것이 X의 경우에 불특정 다수가 제작하는 프로그램이고 윈도그는 계획을 정하고 팀별로 프로그래밍하는 것에서 오는 차이일 수도 있고 계속 개발하는 프로그램이기 때문에 디버그코드들이 산재한데서 오는 문제 점일 수도 있는 것은 애석한 일이라고 생각합니다.
저는 일단 X < 윈도그라는 생각하는 부류입니다. GUI환경은 윈도그나 OSX쪽이 확실히 좋다고 생각합니다.(부팅속도를 따지는 것은 GUI와는 관련이 없으니.)
'현실은 수학으로 표현할 수 없다.'
'수학은 거짓의 학문이다.'
'난 수학이 정말 싫다.'
[quote="snoman"]fender님,X 윈도우가 네트워크 기반
X에서도 다이렉트 렌더링 개념이 있습니다. directFB가 그것이죠. 이는 다이렉트 렌더링과 동일합니다. 하드웨어를 직접 접근하는 방식이죠. 비록 X자체에서 기본적으로 제공하는 방식은 아니지만 충분히 사용할 수 있는 방식임에 틀림없습니다.
그러나 그럼에도 느립니다.(저는 fender님의 얘기를 보면서 어쩌면 구조보다는 어플들의 문제점이 아닐까하는 생각이 더 커져버렸습니다. 그래도 느린 것은 느린거죠. 쩝)
'현실은 수학으로 표현할 수 없다.'
'수학은 거짓의 학문이다.'
'난 수학이 정말 싫다.'
저도 fender님의 지적에 동의합니다. C/S 구조가 물론 그 자체로
저도 fender님의 지적에 동의합니다. C/S 구조가 물론 그 자체로 다이렉트 랜더링보다 손해를 보는 구조임은 틀림 없습니다만 문제는 그 정도가 얼마냐 하는 것입니다. GUI가 구동되는 과정에서 그 통신 뿐 아니라 많은 단계에서 많은 비용이 소모됩니다. 만약 다른 단계에서의 비용이 통신 비용을 압도한다면 C/S로 추가비용이 발생하건 말건 별다른 문제가 안됩니다.
이를테면 J2EE에서 자바 단계에서 온갖 레이어를 다 겹쳐놔도 거기서 발생하는 비용은 데이터베이스에 쿼리 한 번 날리는 비용의 100분의 1도 안되는 경우가 많습니다. 이런 경우 자바단의 레이어들은 속도 결정 요인이 아니기 때문에 아무리 많이 레이어를 겹쳐놔도 전체 성능에 거의 영향을 주지 않습니다.
튜닝에서 제일 중요한 것은 속도 결정 요인을 찾아내는 것입니다. 속도 결정 요인이 아닌 것을 아무리 튜닝해봐야 시스템은 빨라지지 않습니다. X 서버 문제도 GUI가 돌아가는 전체 상황을 프로파일링한 데이터가 없이는 어떠한 논리도 '추측'에 불과합니다. C/S 비용이 폰트 랜더링 비용의 100분의 1일 수도 있는 거니까요.
물론, 저 역시 이 문제에 관한 어떠한 정확한 정보도 갖고 있지 않습니다. 다만 C/S 구조가 X의 치명적인 성능 문제를 야기한다고 주장하려면 단순히 통신하니까 더 느리겠지..정도로는 부족하다는 것을 말하고 싶습니다.
[quote="creativeidler"]물론, 저 역시 이 문제에 관한
정곡을 찌르셨군요.
There is no spoon. Neo from the Matrix 1999.
X가 C/S구조인건 개발되던 당시의 환경을 반영하고 있습니다(X터미널 등
X가 C/S구조인건 개발되던 당시의 환경을 반영하고 있습니다(X터미널 등을 생각하시면 쉬울듯. 요즘 SBC라고 해서 또다시 부활하고 있지만...). 단순히 데스크탑에서 그래픽 카드의 성능을 최대한 이끌어내고 최대한 편리한 U/I에 초점을 맞춘다면 100% X가 안좋은 구조일 수 밖에 없지요.
MS도 원격 터미널 지원 등을 통해서 네트워크 구조를 극복하려는 노력을 하고 있습니다만, 윈도우 단위로 원격에서 불러다 자신의 데스크탑에 넣을 수 있는건 X밖에 없습니다. 그런 장점에 대해서 사용할 일이 없어진 (대부분 PC 1대에서 작업하는) 최근의 x86 리눅스|FreeBSD 사용자에게는 X의 C/S적인 특성은 있으나 마나한 것이니 비교가 무의미하겠지요.
--
익스펙토 페트로눔
어쨌거나..
속도가 개선되야 할 것 같다는 생각은 솔직히 들지만
개선되지 않는다고 하더라도 할말은 없습니다. 올챙이 개구리적
생각 못한다고 정말 예전에는 입에서 욕튀어나오면서 사용했었는데
이제는 조금 속도가 느려도 정말 사용할만 하다는 생각이 듭니다.
예전에는 사양이 월등히 좋은 PC 에서 리눅스를 돌려도 X 윈도우를
사용할때 어딘지 모를 어색함(?) 어정쩡함(?) 같은 느낌이 있었는데
거의 없어진 듯합니다. 다들 느끼실지 모르겠지만 거의 MS 윈도우의
데스크탑의 느낌을 살리려고 노력하는 듯이 보입니다. 체감으로 느꼈던 것은
좋은 마우스로도 느끼지 못했던 미묘한 마우스의 움직임과 커서움직임,
그외에 미묘한 메뉴 오픈과 창의 컨트롤 등등 그리고 메뉴의 구성이나
일반적인 어플리케이션의 응답 등등.. 이런 몸으로 느낄 수 있는 감각적인
부분이 솔직히 윈도우를 주 업무용으로 사용하는 사람들 한테 생기는 몸에 벤
감각적인 부분들이 많이 개선되어서 이제는 주 업무용으로 리눅스를 써도
되지 않을까란 생각이 많이듭니다. (제가 좀 특이해서 스타할때도 마우스 들고
다니는 지라.. ㅡ.ㅡ; 이런 부분에 딴지걸려도 할말은 없음... ㅎㅎ)
파폭으로 인터넷 업무보고 오픈오피스로 문서작성하고 wine 으로 노츠 클라이
언트 돌리면 업무를 X 윈도우 환경으로 사용해도 예전의 어정쩡함을 느끼지
못하니 개인적으로는 이만큼 발전시킨 개발자들에게 감사하게 생각되네요..
마지막 숙제로 파폭의 ActiveX 와 플래쉬 플러그인 문제만 해결된다면 갠적으로
겜을 많이 안하기 땜시 윈도우에서 리눅스 X 윈도우 환경으로 완전전향해도
되겠단생각이 듭니다. 여기까지는 어디까지나 일반사용자의 입장에서 만약에
MS 윈도우 대용으로 리눅스를 데스크탑으로 활용한다면? 이라는 가정하에
말씀 드리는 겁니다..
-------------------------------------------------------------
어쨌거나 저쨌거나 예전에 비하면 정말 감지덕지로 발전한
X 윈도우 시스템에 대해서 개인적으로 찬사를 보냅니다.
위에 글을 읽어 보고 Win2k에 Cygwin/X를 깔아 봤습니다.
위에 글을 읽어 보고 Win2k에 Cygwin/X를 깔아 봤습니다.
Putty에서 X11포워팅 옵션을 켜고, ssh로 연결 후에
X를 띄웠더니 생각 보다. 빠르군요.
glxgear를 실행했더니 평균 200 프레임 이상은 나옵니다. :shock:
Windows의 터미널 서버 보다 훨 낫다는 느낌이 팍팍 오고 있습니다.
KDE 세션을 통채로 띄워도 버벅 거리지 않으니, 편리하고 좋네요.
이게 C/S 구조가 가지는 장점이 되지 않나 싶군요. :wink:
높이 날다 떨어지면.
아푸다 ㅡ,.ㅡ
X Window System과 MS Windows를 비교하는 다른 쓰레드
X Window System과 MS Windows를 비교하는 다른 쓰레드에 글을 올린 기억이 있어서 이 쓰레드라고만 믿고 있었는데 다른 곳이었군요. 그 쪽에 올렸던 내용을 수정해서 다시 올립니다.
http://en.wikipedia.org/wiki/X_Window_System#Common_criticisms_of_X
의 첫번째 문단입니다.
인용하자면,
X에서 network이라는 단점은 unix domain socket을 사용함으로서 충분히 커버가 됩니다. 직접 하드웨어 가속을 이용하는 extension도 많기 때문에 X 자체는 performance bottleneck이 되지 않습니다.
제 생각에 directfb는 서버 클라이언트 코드 자체가 부담스럽고 그러한 transparency가 전혀 필요없는 임베디드 시스템에 어울린다고 생각합니다. 윈도우즈의 RDP와 같이 세션을 끊었다 연결하는 것이 가능하도록 개선하거나 하는 작업은 필요할 지 몰라도 그러한 가능성을 (거의?) 배제시켜버리는 directfb가 X의 대안이 되기는 힘들다고 봅니다.
오히려 요즘의 이슈는 GNOME과 같은 application에 있다고 봅니다. 물론 블랙박스보다 기능도 많고 덩치도 크니 그보단 느릴 수밖에 없죠. 하지만 이게 생각보다 더 느리고 생각보다 메모리를 더 차지한다는 데에 있습니다.
GNOME의 패널에서 시계를 보기 위해 메모리가 10M가 필요하다고 생각한다면 참 거시기하죠. 대부분의 패널 애플릿이 8-10M정도의 메모리를 차지합니다. 물론 VM이 아니고 RSS로요. 각종 서버가 사용하는 메모리 양과 비교해볼 때 너무나 많은 양을 차지하고 있습니다.
게다가 mozilla*, openoffice*, gnome*, (kde*)등이 제각각 라이브러리와 데이터를 로드하니 여기에서도 각종 메모리와 시간 낭비가 있구요. 예를 들어서 문자셋을 변환하는 루틴의 경우 glibc에 한 셋이 들어있고, mozilla에 한 셋이 들어있고, 아마 openoffice에도 한 셋이 들어있겠죠. (gnome은 glibc의 것을 이용하겠죠?) 툴킷도 mozilla따로 openoffice따로 gnome따로...
font rendering같은 경우도 freetype changes를 보니 계속 메모리쪽과 성능쪽 개선이 이루어지고 있는 거 같습니다.
이 외에도 전체적인 성는에 영향을 주는 요소는 너무나 많기 때문에 이런 것들을 종합적으로 생각하지 않고 X 의 network transparency를 victim으로 몰고가는 것은 좀 무리가 있는 듯 합니다.
관련 링크를 많이 찾지는 못했지만 다음 것들이 있습니다. (주로 GNOME의 최적화 필요성에 관련된 것입니다)
http://live.gnome.org/MemoryReduction
http://blogs.sun.com/roller/page/bnitz?entry=thanks_for_the_memories
http://mail.gnome.org/archives/desktop-devel-list/2005-May/msg00050.html
http://lwn.net/Articles/146131/
http://www.gnome.org/bounties/Optimization.html
[url=http://www.freedesktop.org/~jonsmir
The State of Linux Graphics를 참고 하세요.
...
X가 MS윈도보다 좀 느리긴 하지만, 독점드라이버의 퀄리티가 우수한 NVIDIA + Xorg의 결합은 생각보다 만족스럽습니다.
제 생각에는, X의 구조를 개선하고 퍼포먼스를 높이는 것도 중요하지만 VGA벤더들이 신뢰성 있는 드라이버를 만드는 것이 더 선행되어야 할 것이라 봅니다.
No Pain, No Gain.
저는 리눅스를 쓰면서 Ctrl+Alt+Backspace 를 누를 일이 거
저는 리눅스를 쓰면서 Ctrl+Alt+Backspace 를 누를 일이 거의 없더군요.
...제가 행운아인걸까요?
----
블로그 / 위키 / 리눅스 스크린샷 갤러리
....
랜덤의여신님은 행운아 맞아요......
흠.. 참고로.. 뭐 제가 최신에 한 삽질덕분에
openoffice만 띄우면 X가 seg fault먹으면서 죽는건 본적이 있습니다..(아아.. 이런경험은 배포판 만들면서 lib이 꼬인 이후로 정말 오랜만입니다..-.-)
뭐 여튼. 결과적으로는 해결했습니다..
nvidia driver의 버전을 낮추니깐 되더군요...-.-;
..최신driver...역시 무시할 수 없는 내력이 있는것 같습니다....
-----새벽녘의 흡혈양파-----
-----새벽녘의 흡혈양파-----