GUI 우수성. (아래글 참고로..)
음 제가 CUI와 GUI의 1:1문제에 대해 마물을 지어야할때가 온거같습니다.
물론 지금까지 GUI에 그런 개념은 어디서도 없습니다.
그러나 충분한 가능성때문에 말씀드립니다.
일단 CUI에서 가장 특징이라고 하는것은 리다이렉션과 파이프기능인데
이거빼면 특별히 GUI나 CUI나 다를게없죠.
리다이렉션과 파이프의 개념에대해 sun사의 자바워크샵이라는
자바 IDE를 아시는분이있을꺼라생각됩니다. 또 Sun ONE Studio 4 이프로그램에서도
파이프모양을 보실수있을껍니다.
만약 GUI의 바탕화면에서 라인을 그릴수있어서 응용프로그램간에 라인을 이어주면 어떨까요?
탐색기의 글을쓸수있는 텍스트박스 객체에서 메모장의 텍스트박스객체로 선을 그어주고
방향을 메모장의 텍스트박스라인쪽으로 향하게 화살표를 표시해줍니다.
그런다음 탐색기의 텍스트박스 객체에서 글을 쓰게되면 동시에 메모장의 텍스트박스객체로
그내용이 그대로 복사가 되는경우 그런경우도 될수있죠.
또 메모장의 텍스트박스에서 탐색기의 트리부분으로 연결선을 그어주고
메모장에서 텍스트박스로 제어를 할수있게합니다.
뿐만아니라. 네트웍간에 이런원리를 이용할수있을껍니다.
어디까지나 "객체2객체"간의 통신을 그대로 처리해줄수있고
또한 이런 라인들을 저장및 편집도 할수있는것은 당연하겠죠?
물론 제가 능력외라서 이쪽부분을 공부중이지만 무엇보다도 충분히 가능하고
가능하기때문에 1:1이라는 말을 했으며 더했으면더했지 덜하지는 않았을꺼라고
GUI의 가능성에대해 확신하는바입니다. 이것은 절때적으로 유틸리티 레이어에서 구현되는것이 아니겠죠? CUI의 파이프와 리다이렉션이 쉘자체에서 구현된다면 당연히 GUI에서도 GUI쉘(X나 윈도우익스플로러)자체에서 구현되어야한다고 생각됩니다.
제가 GUI의 개발이 CUI에비해 뒤진다라고 말하는것은 CUI자체를
찬사하는분들이 말하는 CUI의 특징이 GUI쉘에는 어디에서도 볼수없기때문입니다. 그래서 그런대안을 생각했구요.
몇가지 문제점이 있습니다. 그러나 충분한 가능성이 있다고 봅니다.
아울러 말씀드리자면 CUI를 욕하러 온것은 절때로 아니고 GUI의 우수성에대해
말할려고 하는겁니다.
절때로 app레이어에대한 평가를 하자는게 아닙니다. 제가말하는것은 app를 돌릴수있는 기반의 쉘에대한(전까지는 ?UI라고 말했던..) 말을 한것뿐입니다.
그리고 게시판관리자님. 스레드를 잠구는것은 정말 유감입니다.
게시물이 누구를 비난하거나 광고성글이 없음에도 불구하고 저의 발언의 자유를 구속하는것은
부당하다고 생각합니다. 다시는 이런일이 없었으면 좋겠다는생각입니다.
필요시 스스로 잠굴수있게 해주세요.
요지를 모르겠습니다.
GUI 새로운 개념에 대한 모색인가요? 그런거면 왜 CUI니 셸이니 끌어들여 이상한 구도를 잡고 이해할 수 없는 논지의 글을 작성하신 건지 알 수가 없습니다.
단락 구분도 엉망이고 띄어쓰기도 엉망이고 좀 정리해주셨으면 고맙겠습니다..
"no error was found with his codes"
제 생각에 이번 GUI vs CUI라는 주제는 충분히 토론해볼 가치가 있
제 생각에 이번 GUI vs CUI라는 주제는 충분히 토론해볼 가치가 있다고 봅니다. 물론 CUI의 모든 기능을 GUI가 대체해야 한다고 생각하지 않지만 어쨌든 유효한 토론 주제입니다.
지난 번 쓰레드가 문제가 됐던 것은 GUI의 장점을 이야기 하면서 오픈소스, 리눅스 할 것없이 논점과 관계없이 마구 끌어들여 비판함으로써 불필요한 flamewar를 유발했기 때문이고, GUI 장점 자체에 대한 주장도 별로 설득력 있는 논거가 없었다고 생각합니다.
이런 부분을 염두에 두고 토론하신다면 이번 쓰레드는 지난 번 보다는 더 나은 토론이 될 수 있을 지 모르겠습니다.
----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...
CUI, GUI
어느쪽도 상대쪽을 대체할수 없다고 생각되는 두가지를 놓고..
서로 비교하는 것이 별 의미 없다고 생각합니다만...
분명, CUI 는 한계점을 가지고 있습니다.
CUI 로 불가능한 몇몇 툴을 생각해 보면 말이죠...
(예로, PhotoShop 류의 툴이나, 개발툴들중 RAD 툴들 같은 경우 말이죠)
하지만, GUI 가 따라올수 없는 CUI 의 장점은 가벼움과 간단함에 있다고 봅니다.
GUI 기반인 윈도우즈는 상당히 무거운 OS 입니다..
GUI 를 구현하는 자체가 많은 리소스를 사용하기 때문이죠..
차후, 하드웨어의 발달에 의해 GUI 를 구현하는데 필요한 리소스가
무시할만한 수준이 된다고 하더라도, CUI 가 더 가벼운것은 변하지 않을 것입니다.
또한, GUI 는 과도한 마우스의 사용을 요구합니다.
(단축키 등으로 많이 줄이고 있지만, 여전히 마우스를 많이 사용해야 하죠.)
타이핑 중 마우스를 사용한다..별거 아닐거 같지만,
많은 시간을 빼앗기는 요소입니다. 마우스를 쓰기 위해 손을 옮기는 그 잠깐때문에라도
작업효율은 많이 떨어진다고 생각합니다.
CUI 에 비교되는 GUI 의 강점은 접근성(?) 이라고 생각되는군요.
어떤 환경을 처음 접하는 사람이라면, CUI 보다는 GUI 가 익히기가 더 쉽기 때문에
저런 단어를 생각해낸 겁니다.
또한, 위에서도 말했다시피, GUI 로만 가능한 것들도 존재하죠.
하지만, 위에서 말한 CUI 의 강점은
아직 GUI 가 해결하지 못한 것들입니다. 해결 가능할지도 의문입니다.
글 쓰신 분께서 제시하신 '파이프' 의 경우에도..
CUI 가 익숙한 사용자라면 CUI 기반의 쉘이 더 편하고 빠르겠죠.
간단히 '|' 하나만 타이핑하면 되는것을 마우스로 선을 긋는다...
아무리 마우스 사용이 빠르더라도 느릴수밖에 없는 경우가 아닐까 싶군요.
Re: GUI 우수성. (아래글 참고로..)
제 단순한 사견입니다.
두 인터페이스의 차이는 어떤 부분에 중심을 두는가라고 봅니다. CUI는 일반적으로 명령을 내립니다. 많은 명령어는 일반적으로 동사에 바탕을 둔 것이고 영문법중 명령형 문장과 유사합니다. 실제 프로그램을 하나의 동사로 보고, 필요한 명사-목적어, 대상 정도가 되리라 생각합니다-를 넣는 방식입니다.
반면에 Mac이나 Windows, Gnome등의 데스크탑 중심 GUI들은 동사보다는 명사(목적, 혹은 대상)중심의 작업을 합니다. 실제 파일을 복사하거나 이동할 때 마우스로 드래그, 혹은 특정키와 조합하는 명령을 내리는데 이것은 개개의 대상을 중심으로 작업하는 모습을 좋은 본보기라고 생각됩니다.
또한 최근의 데스크탑 중심의 GUI가 보여주는 특징은 개개의 대상이 자신이 작동하는 방식을 규정한다는 것입니다. 일반적으로 확장자를 이용하거나(Windows), 파일 자체에 대한 정보를 별도의 장소에 정의(Mac OS 9을 포함한 이전의 Mac OS, Mac OS X는 사용하지 않아 모르겠습니다.)하는 방식등을 이용해, 실제 파일의 성격을 규정함으로써, 동작방식을 대상에 포함시키게 됩니다.
문서를 편집하려는 행위를 통해서 이런 명령중심인가, 대상중심인가는 모습을 잘 알 수 있다고 생각합니다. 일반적으로 명령중심인 경우는 대상을 사용하기위한 명령을 정한 이후에 대상에 대한 정보를 기입하며, 대상 중심의 경우는 먼저 대상을 정한 이후 명령이 수행됩니다. 도스나 쉘상에서 Vi something.txt로 문서를 편집하는 것과 GUI 데스크탑에서 문서를 더블클릭등의 방식을 통해 여는 차이라고 할 까요?
물론 GUI환경에서도 일단 명령(편집기등의 응용프로그램)을 실행한 후 대상(소스 파일, 혹은 기타 다른 요소)을 설정할 수도 있으며, 특정 CUI환경에서는 대상의 이름을 명령어 줄(Command Line)에 입력하는 것만으로 원하는 프로그램을 수행할 수 있습니다만 제가 볼 수 있었던 일반적인 환경으로 범위를 줄인다면 명령중심의 사용자 인터페이스보다는 점차적으로 대상중심의 인터페이스로 옮겨가는 모습이고, 그 바탕이 CUI보다는 GUI에 더 맞춰졌다고 봅니다.(예외적인 상황이 있다면 알려주십시오. 저도 UI에는 관심이 조금 있어서 아마추어적이긴합니다만 연구비슷한 것을 하고 있습니다.)
제 생각에 CUI와 GUI의 차이를 논한다기보다는 특정한 명령중심이냐, 대상중심이냐로 문제를 보는 편이 더 효과적인 것은 아닐까 생각합니다. 그런 것이 인간-기계 시스템에서의 인터페이스에 대해 좀 더 근복적으로 바라볼 수 있는 것은 아닐까요.
대상중심의 인터페이스가 증가한다는 나름대로의 견해를 비약시킨다면(물론 이래서는 곤란하겠지만, 어디까지나 개인적인 견해임을 말씀드리겠습니다) 사용자가 사용하는 모든 대상물-현재 시스템에서의 파일이라고 할 까요?-은 자신이 어떻게 동작하는 지를 알고 있으며, 사용하고 있는 운영환경상에서 지원하지 못한다면 Network등의 주변요소를 찾아서 스스로 동작하는 것도 생각할 수 있겠지요. 예전에 본 어떤 글에서 이러한 시스템을 구축하는 환경을 본 것 같은데 정확한 출처를 말씀드리지 못해 아쉽습니다. (몽상적이기도 했습니다만 상당히 매력있는 인터페이스였습니다.)
그 이외에 많은 플러스 요소가 있을 수도 있겠지요. 특정작업을 하는데 있어서 연관되는 다른 작업 사용빈도가 높은 경우, 예를 든다면 C소스파일을 보는 경우 함수분석툴과 디버그 프로그램이 다른 프로그램보다 월등히 많이 사용된다는 등의 상황이 주어진다면 사용자가 어떤 C소스파일을 보는 경우 운영환경에서 자동적으로 함수분석툴과 디버그 프로램이 뜬다면 편리할지도 모르겠지요. 귀찮을수도 있지만 말입니다.
PS> 다시살펴보니 엉뚱한 얘기를 써버렸네요. 확실히 생각을 정리하는것이 점점 힘듭니다. 게시판 돌아다니며 즉흥적으로 한줄 답글쓰는데 너무 익숙해져 버린것이 이렇게까지 영향을 미치는군요. 머리속으로 떠오른 생각을 정리된 글로 옮긴다는게 엉뚱한 결과로 바뀌고 말았습니다. 타이핑한 수고가 아까와서 올립니다. 너그러운 마음으로 봐주시길.. :oops:
새로움을 느끼기에 삶은 즐겁다..
모험가 아돌 크리스틴을 꿈꾸며..
Sia..
저는 CUI와 GUI는 서로 양립할 수 있다고 봅니다. 더 나아가, 양쪽
저는 CUI와 GUI는 서로 양립할 수 있다고 봅니다. 더 나아가, 양쪽 모두를 지원하는 것이 이상적이라고 생각합니다. 그리고 실제로 그렇게 동작하는 프로그램들이 많이 있습니다. 윈도우즈의 explorer.exe만 해도 커맨드 라인에서 몇가지 옵션을 주고 구동시킬 수 있습니다. 윈도우즈 2000 에서도 명령행 프롬프트를 위한 굉장히 다양한 종류의 시스템 관리 유틸리티들을 지원하고 있다는 사실을 아십니까?
분명히 GUI가 사용자에게 친숙한 것만은 사실입니다. 그러나 그러한 점보다는 CUI의 도구들간의 상호 연결성이라던지 배치 처리가 중요하게 여겨지는 분야도 분명히 존재합니다. 저는 아직도 단순반복업무에는 때때로 .bat 파일을 사용하는 경우가 있습니다. 또한 수백개의 파일 확장자를 동시에 바꿔야 할 때에는, 별 수 없이 명령행 프롬프트를 열고 ren을 씁니다.
또한 특별한 환경에서는 GUI가 다소 부담이 될 수도 있습니다. 느린 속도의 회선으로 연결되어 있다던가, 환경 자체가 GUI를 돌릴만큼 부유하지 못하다면 어쩔 수 없이 CUI를 선택할 수밖에 없습니다.
가장 중요한 것은 '원하는 문제를 해결하는 것'입니다. CUI나 GUI는 목적을 달성하기 위한 도구에 지나지 않는 것이지, 목적 그 자체가 될 수는 없습니다. 목적을 달성하는 데 가장 효율적인 방법에 따라 어느 한쪽이나 또는 둘 다를 선택하면 되지, 꼭 어느 한쪽만을 강요해야 할 필요는 없다고 생각합니다. CUI면 어떻고 GUI면 어떻고 VUI면 어떻습니까?
CUI, GUI의 문제는 아닌 것 같습니다.
제가 님의 글을 읽고 님이 생각하는 것이 무엇인지 생각해 보았습니다.
그 배경은 컴포넌트 모델일 것 같더군요.
쉘에서 파이프는 바이너리들간의 통신에 활용됩니다.
그리고 그 파이프를 네트워크상으로 확장해서 소켓이라는 것도 만들었습니다.
그걸 GUI쪽에서 찾아보면 MS의 COM+같은 것일 겁니다.
그런데 이런 컴포넌트 모델은 이 동네(?) ^^ 에서 위젯이라고 부르는 것들만 다루지 않습니다.
DB컴포넌트도 있고 그렇죠.
그래서 그걸 GUI로 한정할 수는 없을 겁니다!!
지금의 인터페이스하에서...
일반 사용자들은 이런 컴포넌트들을 Copy&Paste를 통해 사용한다고 볼 수 있습니다.
단순한 문자열 복사를 넘어 여러가지 Copy&Paste가 됩니다.
컴포넌트 모델을 통해서 Excel의 "표"가 Word의 "문서"에 붙어 버립니다.
컴포넌트 모델이 있었기에 가능한 일입니다.
컴포넌트 모델은 여러가지가 있습니다.
Gnome쪽에서는 Bonobo가 이런 역활을 해주고 있습니다.
OpenOffice에는 OpenOffice의 컴포넌트 모델이 있고
KDE에는 KDE의 컴포넌트 모델이 있고
Mozilla에는 Mozilla의 컴포넌트 모델이 있습니다.
해당 사이트에서 문서도 찾을 수 있을 것입니다.
해본적이 없어서 잘은 모르겠지만
아마도 이런 까닭에 Koffice의 스프레드쉬트에서 표를 짤라서
AbiWord에 붙힐 수는 없을 겁니다.
컴포넌트 모델때문이죠.
되려면 브릿지를 만들던지 같은 모델을 쓰던지 해야 할 겁니다.
지금의 인터페이스하에서...
일반사용자는 그 이상 사용하지 않는 것 같습니다.
그 이상의 사용은 개발자 수준에서 이뤄집니다.
바로 RAD툴이죠.
dummy999님이 얘기하시는 GUI를 본 적이 있다면
그것은 일반 desktop이 아닌 RAD개발툴일 것입니다.
데이타베이스에서 SQL말고 쓰는거 본 적있다는 님의 얘기도 본 기억이 있는거 같은데
그것도 개발환경이죠. ^^
MS플래폼을 예로 들었으니깐 비주얼 베이직을 예로 들어보죠.
비주얼 베이직은 Windows컴포넌트(COM객체)를 조립할 수 있게 해 줍니다.
대부분의 MS프로그램이 그러하듯이
MSIE는 COM객체입니다.
비주얼 베이직 조금 배우면 MSIE의 그것을 끌어다가 자신만의 웹브라우저도 간단히 만들 수 있습니다.
dummy999님께서 마우스 선긋기로 객체간에 연결을 할 수 있는 인터페이스를 말씀하셨습니다.
그것은 지금의 desktop수준을 넘어서는 RAD 개발환경 수준입니다.
비주얼 베이직에서 Windows컴포넌트들을 이것저것 가져와서 붙힙니다.(연결합니다.)
그리고 플레이 버튼을 누르면 이것저것 붙힌 것들이 원래 하나였던양 그렇게 잘돌아갑니다.
그 궁극에는 그렇게 돌려줄 인터프리터가 있습니다.
파이프로 유틸리티들을 연결해서 돌리려면 쉘이 필요한거랑 같은 이치입니다.
같은 이치로 마우스 선긋기로 연결한 객체들이 서로 유기적으로 돌아가려면 인터프리터가 필요할 것입니다.
그런 환경은 Windows에도 MacOS에도 없습니다.
RAD개발툴에서 지원하고 있을 뿐입니다.
그리고 비주얼 베이직이 그러하듯이 쓸모있는 무엇이 되려면 결국 궁극에는 "코드"가 필요할겁니다.
와우 리눅스 게시판에 가보니 자기가 쓴 글을 제목만 1로 남겨놓고 내용은
와우 리눅스 게시판에 가보니 자기가 쓴 글을 제목만 1로 남겨놓고 내용은 전부 지워버리는 엽기적인 행각을 벌이는 김진철님이라는 분이 계시던데, 아마 dummy999님 맞지요? 다른 분들의 답장글을 읽어 보니 인터페이스, GUI, 기타 등등 지금 하고 계신 말씀과 아주 비슷한 내용으로 줄곧 말씀을 하셨더군요.
과연 무슨 말씀을 하시고 싶어서 같은 주제를 해가 바뀌도록 되풀이하시는지 궁금합니다.
주위에서 아무리 설득을 하려해도아무 소용 없는 분이시네요.다른
주위에서 아무리 설득을 하려해도
아무 소용 없는 분이시네요.
다른 모든 분들을 설득해보고 싶으시면요.
직접 만들어서 보여주세요.
이런 소모적인 논쟁을 반복하는 것보다
그게 훨씬 생산적이라고 생각하지 않으시는지요 ?
Re: GUI 우수성. (아래글 참고로..)
딴 거 다 필요 없구요.
우수하게 돌아가는 GUI 하나 만들어서 보여주시면 다들 설득하실 겁니다.
아... 저도 OS/2 를 주 OS 로 쓰기 때문에 GUI 팬입니다....
그리고 말씀하신 마우스 선긋기는 OS/2 에서는 1992년 이후로는 아무때라도 되어오던 것입니다. - 정확하게는 OS/2 2.1 이후에는 WPS 가 어느정도 정형화 되었고, 단순한 GUI 가 아닌 것이 되어버렸지요.
그 가장 발전되었다는 형태의 WPS 에서 조차도 ... CUI 는 꽤 필요합니다. rexx 등으로 처리해야 할 일이 무지하게 많거든요. 물론, vrexx 라 하여 비주얼 Rexx 로도 충분히 되기는 하지만, 그건 껍데기를 씌운 거죠.
IBM 처럼 직접 만들어서 보여주면 많이들 인정하실 듯 하군요.
---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도
즐겁게 놀아보자.
개인적인 부탁입니다만...
아주 개인적인 부탁입니다만,
http://bbs.kldp.org/viewtopic.php?t=22174&highlight=에서 처럼 남의 글을 이상하게 인용하지 말아주었으면 좋겠네요.
인용 태그는 남이 한 말을 따올 때 쓰는 것입니다.
"M.W.Park 씀:" 밑에 따라나오는게 제가 쓴 글이 아닐 때 너무 당혹스럽더군요.
해당 스레드에 올리려 했으나 간발의 차로 스레드가 잠기는 바람에 여기에 올립니다.
-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂
제 생각에는...
gui, cui 둘다 나름대로 좋습니다. gui가 더 편한 환경에서 gui를 쓰고, cui가 더 편한 환경에서 cui를 쓰면 되는 것입니다.
단, 아무리 gui가 발전해도 cui를 따라가지 못할 환경은 얼마든지 존재할 것이라는 것이 제 생각입니다. 그 반대도 마찬가지고요.
cui가 gui를 대체할 수 없다는 것은 대부분의 분들께서 인정하실 것 같지만,
gui가 cui를 대체할 수 없다는 것은 의야해하실 분이 계실 지 모르겠습니다.
UI는 컴퓨터와 대화하는 방식 내지는 언어입니다.
무엇을 어떻게어떻게 해라 하고 명령을 내리는 수단이죠.
제가 봤을 때, gui의 치명적인 문제점은 vocabulary의 부족입니다.
한꺼번에 access할 수 있는 object 갯수가 제한되어 있고, 한꺼번에 access할 수 있는 조작 방법이 제한되어 있고... 뭐 이런 식입니다.
예를 들어,
find /home/ihavnoid -name *.mp3 -exec mv {} /var/mp3s/ \;
이 unix command를 만일 윈도우즈(혹은 앞으로 나올 수 있는 최첨단의 gui)에서 할 수 있는 방법이 무엇이 있을까요?
윈도우즈에서 하자면, 탐색기를 띄워서, /home/ihavnoid에서 *.mp3 로 검색을 하고, ctlr-a, ctrl-x 를 하고, /var/mp3s를 열어서 ctrl-v 를 할 것입니다.
유닉스에서는 위의 명령 치는 데에 몇 초 안 걸립니다. path가 기억 안 나면 자동완성 같은 것의 도움을 받을 수도 있습니다.
제가 생각하는 gui의 문제점이 바로 이것입니다. /var/mp3 라는 객체를 access 하기 위해서는 현재의 상황에서는 최소한 마우스 클릭을 세번은 해야 할 것입니다. (shortcut이 없다는 전제하에) 물론 1클릭에 모든 것을 access할 수 있는 방법을 만들면 화면이 너무나도 난잡해져서 골치가 아파지겠죠.
cui에 익숙한 사람은 위에 제가 써 놓은 명령어 입력하는 데에 5초 이하가 걸립니다. gui에서는 5초는 커녕 10초도 어림도 없죠.
객체뿐만 아닙니다. 동작 역시도 gui로 표현할 수 있는 것이 제한되어 있습니다.
cui의 단점은 많습니다. 그렇지만 다들 잘 아시리라 생각되므로 생략합니다.
Consider the ravens: for they neither sow nor reap; which neither have storehouse nor barn; and God feedeth them: how much more are ye better than the fowls?
Luke 12:24
쩝. 이런 소모적인 논쟁을...
이 스레드가 다시 생겨있는줄은 몰랐네요. 좀 xx이 나려고 합니다.
굉장히 소모적인 논쟁이 아닌가 싶은데요.
GUI와 CUI의 근본적인 차이는... 아마도 검지 손가락이 j와 f를 떠날 필요가 있느냐 없느냐가 아닐까요. :D
아... 저 유닉스 광팬이지만, 코딩할때 말고는 윈도우만 씁니다. 그러면서도 가끔씩 mp3파일 이름을 f2와 마우스와 키보드로 바꾸고 있노라면 xx이 부글부글 끓어오릅니다.
여튼. 이얘기는 좀 그만해도 좋지 않나요. 머릿속으로야 이론상으로야 다 가능한거 여기 모르는 분 계시나요. 원체 되는걸 보아야 하는 컴퓨터쟁이들 습성이야 그러면 너가 만들어서 가져와... 라고 얘기할건 뻔한 일인것 같은데요. 제가 타이핑하고 있는 것도 좀 바보같은 짓이라고 생각합니다만...
이제 그만하는게 좋지 않나요?
...
벌써 몇해째 쓸대없는 논의만 반복하는지 모르겠군요.
GUI인정합니다.
CLI와 GUI를 두고 어느게 좋고 어느게 나쁘다는 식의 논의는 인정하지 않지만 GUI의 장점에 대해서는 인정합니다.
그렇지만 누군가는 만들어야하는데 목마른 사람이 우물을 파야되지 않겠습니까?
직접 만들어 주십시요.
말만 하실려거든 어떠한 방식으로 하면 좋을까라고 말씀하시고 본인의 생각을 남에게 강요하지 마십시요. (그런식으로 글을 올리면 아이디어가 필요한 누군가가 만들지 않겠습니까?)
[/b]
이 답글이 누군가를 짜증나게 할지도 모르겠군요 ^^
전 이러한 논의가 자꾸 나오는게
GUI의 우수성을 논의하면
CUI의 우수성을 논하며 GUI의 단점을 논하며
그러면 거꾸로
GUI만의 장점을 논하며 CUI의 단점을 지적하는...
물고 물리는 논의가 이어지고 있는 것 같군요
거기다가 논의를 더 "감정적인", 혹은 "서로 짜증내는 분위기"로 몰고 가는 것은
은근히 비꼬거나,
혹은 의도하지 않았는데, 결국 비꼰셈인 경우가 많지요.
(위에 답글다신 여러분들의 글들에서도 볼수 있는듯.)
예를 들다면, 네가 한번 만들어봐라, 말은 쉽지..등등 ㅡ.ㅡ
특히 가장 경계해야 할 것은
그 대상들의 비교를 해야지
그것을 사용하는 사람의 소양을 문제 삼는 다면, 논지를 흐리는 셈이죠.
이건 특히 리눅스/윈도우에 대한 얘기가 나올때 특히 심한데
일부 분들은 (일부입니다) 윈도우 사용자는 잘 몰라서
그게 좋은줄 알고 쓴다..는 식의 접근은 뭔가 아닌것 같거든요.
말이 자꾸 길어지는군요 :)
쓰레드와 직접 관련이 없는 답글에 누군가 짜증을 낼까..두렵습니다만 ㅡ.ㅡ
답글들을 보다가..뭔가 답답해서 굳이 달아봅니다^^
이스레드는 소모적인 논쟁이 아닙니다.
복잡하게 말하는것은 말그대로 소모적인논쟁일뿐입니다.
하지만 제가 글을 쓴건 소모적인논쟁이 아닙니다.(적어도 저는 그렇게 생각하거든요)
그렇게 보신다면야 글을 안쓰셔도 좋을껍니다. 적어도 제글에 글을써주신분들은
그런소모적인 논쟁이 아니라고 생각하신분들이 많을꺼라생각합니다.
그래서 그냥 일축한 글로 썼습니다.
제가 메모장에 글을 써서 올립니다. 바로 글을 올리면 글에대해 잘못된점이 있을수있을꺼같았는데
이렇게 글을 쓰다보면 인용할때 일일히 태그이름을 써주기때문에 잘못써질수도있는거같네요
ihavnoid 님 님께서 지적해주신방법역시 어떤의미로 파이프로서 처리가 가능한게 아닐까 합니다.
뭐 아니면 어쩔수없지만. 제가 위에 쓴글을 조금응용하면 지적하신 부분역시 쉽게 처리되지않을까
하는 생각도 듭니다. 음.. 그런데 조금 머리를 써야할지도 모르겠다는 생각도듭니다.
그리고 제차 말씀드리지만 소모적인논쟁은 안합니다.
그렇게 보는이유를 모르겠군요. 글을 쓰면서 자꾸 이런말을 하는데요.
어떤 UI가 좋다 나쁘다. 절때로 그런말은 하지마세요. 그런말을 원하기위해 스레드를 연게 아닙니다.
제글에 리플다신분들도 그것을 알면서 그런리플을 단다는것자체가 더욱소모적인 논쟁이 아닌가요?
다시한번말씀드리지만 그런글은 빼주세요.
아울러 말씀드리지만 GUI에서 가능한것과 CUI에서 가능한것의 비교및 차이점을 말하는게 소모적이다라고 말하기엔 조금 어패가 있습니다. 이것으로 자웅을 가리고 싶은 마음은 없습니다.(물론 제가 자웅을 가린다해서 그것이 진리가 될꺼라고는 생각해본적도 없으니까요) 그러니까. 그런쪽으로 몰고가지마세요.
몇몇 분들은 그래도 제글에 대한 의도를 잘이해해주시면서 글을 써주시는데 다른몇분들은 글을 그렇게 오해하시면 저로서도 의도한작업을 하기 힘들어집니다.
그리고 직접만들어달라는 말이 많았지만. 저역시 노력을 안해본바는 아닙니다.
그런데 만들다보면 내가 뭐를 만들어야하는지, 어떻게 만들어야하는지, 왜만들어야하는지 그것을 망각해버립니다. 그것은 제가 초보라서 그렇다고 생각합니다. 그리고 지금 그결과로 문서작업을 하고있습니다. 그래도 좀처럼 진척이 없습니다. 제가 워낙 처리효율이 떨어지기 때문에 작업하는데 상당시간을 지체해왔고 앞으로도 그렇게 될꺼같다는 그런생각이 걸립니다.
4번생각한게 적다면 적을 수있고 그렇게 해서 또다시 비슷한말이 나오면 제가 바보같아서 겠죠
그러나 이글을 쓰기까지 4번을 고쳐썼습니다. 소모적인논쟁 이스레드는 아닙니다. 몇년동안 문서화하는게 지쳐서 좀더 공개적인 형태로 문서작업하고 싶어서 글을 쓴거니 절때로 오해하지 마시길.
------------------------------------
F/OSS bless you... ^^*
쩝...
대체....에혀..
이런걸 즐기는 건지...
뭐하자는 건지....
휴...
제너릭...
음....
끝나가는 토론에 뒷북치는게 아닌가 걱정이 들지만
적어봅니다.
물론 될수만 있다면 GUI 쪽으로 가야 합니다.
하지만 유닉스를 사용해보신분은 아무리 좋은 윈도우를 사용하더라도
쉘에대해 향수를 느낍니다.
쉘(유닉스의 CUI)는 제너릭합니다. 아니 유닉스 자체가 제너릭하죠
그래서 좋은겁니다.
CUI가 좋은건 마우스를 사용하지 않는다 정도입니다(이것이 단점이 되는경우도 많지만)
제너릭한것이 정말 좋습니다.
-- 아쉬운 하루 되세요 --
CLI에 한표.
아직은 CLI 위주에 GUI 보조인 리눅스가 젤 편합니다.
Re: GUI 우수성. (아래글 참고로..)
同感
도구의 결함은 장인의 손으로 극복한다.