cygwin의 분류..

dummy999의 이미지

cygwin을 종류로 구분지어야할때 이것을 정확히 어떤장르에 넣어야 좋을까요?
에뮬레이터라고 해야할지 아니면 그냥 유틸리티일련지 아니면 또다른쉘이라고 해야할지..
왜냐면 cygwin은 그만큼 모호성이 있어보이기때문입니다.
저는 이게 쉘쪽에 가깝다고생각합니다.
어떤쉘이든간에 커널과 통신을 하고 그기반에서 APP를 돌리기때문에
그런속성을 cygwin은 만족하고있다고 생각하기때문입니다.

아울러 이건 질문인데 걍 쓰는김에 같이 쓸께용.
cygwin에서 linux_logo라는 프로그램을 돌릴려고하는데 이걸쓰려면 glibc가있어야합니다.
이것이 뭐하는 라이브러리이며 또 cygwin용에서 돌릴려면 어디가서 받아야하는지
궁금합니다.

참고로 첫질문은 철학적인개념이 있을꺼같아서 여기에 넣습니다.
두번째 질문은 꼽사리입니다. 그래도 두번째 질문에도 답좀 해주세용 ^^;

pynoos의 이미지

쉘이라는 표현은 대개 command parser에 가깝고, 그 하위 레이어가 커널이라기보다는 posix 혹은, system library (libc 등을 포함한)에 가까운표현인 것 같습니다.
윈도우에서도 쉘하면, User Interface에 있는 explorer 혹은 그 하위 레이어로 script engine, registry, 파일, 폴더에 대한 일반적인 인터페이스 등을 말합니다.

제가 보기엔, WinNT kernel 위에 있는 Win32와 같은 layer 혹은 Win32 를 한번더 감싼 posix layer 라 이해됩니다.
emulator라고 되어있지만, 전혀 머신어 구조가 다른 내용을 이해하여 실행하는 virtual machine이나 오락 에뮬과 같은 것이 아닌, 실행파일입니다.

따라서, 제가 보기엔, cygwin 은 단지 porting layer 라고 이해 됩니다.
porting layer라는 것이 원하는 장르라는 것에 있는지는 모르겠군요.. :)

ihavnoid의 이미지

위엣분 말씀대로 porting layer라는 게 적합한 표현일 듯 합니다.
단순히 쉘 하나라고 얘기하기에는 너무나도 광범위한 기능을 지원합니다.
하다못해 X도 띄울 수 있고, gnome도 띄우고 뭐 그런다고 하더군요.

하나의 OS 상에다가 다른 api를 올린 것이므로, shell이라는 표현과 emulator이라는 표현 둘 다 부적합하다고 보입니다.

그리고 glibc는 GNU의 표준 c 라이브러리입니다. printf 등의 표준 c 함수들 뿐만 아니라, 사용자가 가장 기본적으로 필요한 기능들을 모두 갖추고 있죠. MS로 비유하자면 msvcrt랑 몇개의 코어 dll들을 합친 것이라고 생각됩니다.
(정확한 비유일지 모르겠지만)

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

monpetit의 이미지

dummy999 wrote:
cygwin에서 linux_logo라는 프로그램을 돌릴려고하는데 이걸쓰려면 glibc가있어야합니다.
이것이 뭐하는 라이브러리이며 또 cygwin용에서 돌릴려면 어디가서 받아야하는지
궁금합니다.

cygwin이 돌아가고 있다면 이미 glibc 런타임이 설치되어 있는 겁니다.
cygwin1.dll을 찾아 보세요. 이것이 glibc 런타임 + 알파(pthread 등)로 구성되어 있는 겁니다. Windows용 프로그램에서 빠질 수 없는 것이 msvcrt.dll 등이듯이 cygwin용 프로그램을 사용하기 위해선 반드시 함께 따라다녀야 합니다.
dummy999의 이미지

우선 커널이라는것은 그냥단순한정의로 봤을때
사용자로부터 기계를 제어하는데 필요로하는 일련의 명령들을 담아두는곳을 의미하겠고
그런형태는 사용자쪽보다는 기계쪽에가깝다고 보는편이 좋을듯합니다.
그래서 사용자가 직접적으로 명령을 줄수는 없죠.

그위에서 쉘이라는게 인간의 명령을 번역해주죠. 다시말해 인간과 기계사이에서
커널은 기계쪽의 인터페이스를 쉘은 인간쪽의 인터페이스를 해준다고 봐야합니다.
그런데 이것들은 객체라는 단위로 볼수있습니다.

객체에는 다른어떤객체에도 종속적이지않는다는 원래의 속성을 봤을때
쉘이나 머신이나 인간이나 커널의 객체는 서로 자신의 위치를 굳건히 지킬수있지만.
어떤것에도 종속적이지않는다는것을 의미하기도합니다.
다시말해 머신의경우엔 대부분 펜티엄씨리즈에대해서는 어떤 OS커널이라도 부착할수있다는거고
그런 OS커널위에서 쉘이돌아가는데 X라는 쉘형태의 유틸리티도 돌수있고
CUI도 돌릴수있습니다.
그리고 그위에서 쉘에게 명령을 단계인 인간역시 내가 아니더라도 다른 어떤인간이라도
쉘에게 명령을 줄수있죠.

이처럼 각각의 레이어들이 서로의 영역을 넘어서지않고 동급에서 서로가 독립적인형태가
가장완벽한 설계라고 볼수있을꺼같습니다.

그리고 이런객체들은 동일한 객체간에 통신을 할수있기도 합니다.
예컨데 머신은 다른머신과 통신을 할수있기도하는데 이런건 분산환경에서 많이 쓰이기도 하죠
또 OS의 경우엔 그런경우가 드물지만
인간의 객체라는것역시 다른누군가와 끊임없이 통신을 합니다.

A라는사람이 Z라는머신에 윈도우를 깔수도있고 유닉스를 깔수도 아니면 다른어떤걸깔수도있는데
그것은 자유이고 B라는사람은 A에게 그것을 시킬수도있는데 이때 A가 하던말던 A의 자유이기때문에
독립성은 유지되는거겠죠.

cygwin역시 쉘의 속성을 많이 가졌다고 봅니다.
물론 이를 부정하는분들이 많을껍니다.
그러나 CYGWIN은 쉘이가지는 속성을 모두만족합니다.
다른 APP를 자신위에서 돌릴수있고 직접또는 간접적으로 커널과 통신도 합니다.
간접통신이란 API를 통한 통신일수도있다는의미도 됩니다.
반드시 쉘은 커널과 직접통신을 해야 쉘이된다라는 표현은 맞지않을껍니다.
같은레이어라면 또다른 동일객체를 실행시킬수도있는건 당연한거라고생각합니다.

예컨데 커널이 또다른커널을 적제시킬수있고 사람이 또다른사람을 부를수있고
머신이 또다른머신에게 작업요청을 시킬수있듯.. 그렇게 하면 쉘역시 또다른쉘에게
작업요청을 하지말라는법이 없습니다.

유닉스를 보면 CUI에서 X를 호출하기도 하니까. X를 쉘로본다면 쉘이 쉘을 호출하는그런거겠죠?

물론 그에대한 성능저하는 어쩔수없겠지만. 필요하다면 그것도 가능하게 설계해야 된다는게 저의
생각입니다. 물론 얼마나 가능할지는 몰겠습니다.

결론은 cygwin역시 쉘이라고 생각합니다.
개인적으로 지금존재하는 라이브러리들을 이해하고 기억할만큼 능력도 똑똑하지도 않습니다만.
모든것을 가장 기본적인 시점에서 바라보려고는 합니다.
다시말해 어떤것이든지 2차 3차 테이블을 참조하지않고 1개의 테이블만으로도 어떤것이든지
개념을 잡을수있다고 생각합니다.

포팅레이어라는건 어느계층이 되는지 잘몰겠지만. 좀더 쉽게 설명을 해주신다면 이해가 빠를것같습니다.

참고로 제가 개념을 잡고있는 레이어는 다음과같습니다.
한가지 일(계획(인간(인간->..->인간)->sw(app -> 쉘->..->커널->..)->HW(머신->..->머신)) ->행동(작업결과))
보기가 복잡합니다. 어디에도 안나와있는거같더라구요.
이건 트리모양으로 표현이 되죠. 그리고 각노드들은 동일의 다른노드와 통신을 할수있습니다.

여튼 이렇게보면 포팅레이어라는쪽은 어느쪽에있어야할지 잘몰겠더라구요.
(개념을 그렇게 잡았는데 틀린부분이있다면 답변부탁드립니다.)

------------------------------------
F/OSS bless you... ^^*

pynoos의 이미지

cygwin 이라고 말할 때는 두가지를 생각하게 되는 것 같습니다.

하나는 cygwin1.dll 과 또 다른 것은 cygwin 설치시에 따라오는 모든 것.

마치 리눅스 커널과 배포본의 관계 비스무리한 생각이 들기도 하는군요
같이 배포되는 binary 들은 단지 cygwin 환경에서 compile 되었을 뿐, 구 시그너스사에서 만든 것은 아니죠.

Quote:
sw(app -> 쉘->..->커널->..)

쉘이라는 놈이 인간의 명령을 받아 어떤 프로그램을 실행하지만, 그 실행된 프로그램은 대부분, 거의가 다.. 그 쉘을 통해 OS에 접근하는 것이 아닙니다.

이런 관점에서, cygwin 이라하는 놈을 처음 실행하게 되면, bash 가 실행됩니다만 이것은 사실 cygwin1.dll 을 이용하는 쉘일 뿐이죠.

따라서, 만약 cygwin 을 cygwin1.dll 이라는 관점에서 볼 때 Win32 API(kernel32.dll) 나 커널(ntdll.dll) 위에서 돌아가는 posix layer를 link 하기 위한 포팅 레이어로만 보일 뿐입니다.

이 cygwin bash 에서 실행시키는 모든 프로그램들은 단지 win32 혹은 nt 커널의 프로세스 생성 방법에 의해 실행 시키는 것일 뿐입니다. 따라서 이들 프로그램이 만일 cygwin1.dll을 사용한다면 사용하는 것이고, bash 에서 기존 windows 응용 프로그램을 실행한다면, 그것들은 cygwin1.dll 과는 전혀 상관 없는 것이 되겠습니다.

제 생각은 cygwin1.dll 이라는 것에 cygwin의 위치를 맞추어야한다고 생각하며, 이 dll은 단지 하나의 layer를 제공함으로써 Unix 계열에서 사용되는 코드를 큰 수정 없이 사용할 수 있게 하는 것에 그 의미를 두어야 한다고 생각합니다.

unipro의 이미지

Quote:
sw(app -> 쉘->..->커널->..)
제가 배운 기억으로는 위 구조가 아니라 sw[app(쉘, 워드프로세서...) -> {인터프리터(쉘, 펄...)} -> {lib(glibc, cygwin1, msvcrt... )} -> 커널->..] 인 것 같습니다.

쉘은 인간과 운영체제의 대화(?)를 제공하는프로그램입니다. 대표적으로 인간이 내린 명령어를 파싱해서 운영체제에게 전달하는 일을 합니다.

바이너리로 컴파일된 프로그램은 쉘을 통해서 커널과 통신하는 것이 아니라 직접, 또는 라이브러리를 통해서 운영체제와 통신할 것입니다.

내 블로그: http://unipro.tistory.com

dummy999의 이미지

저는 쉘자체가 인터프리터와 API(라이브러리)역할을 하고있다고 생각합니다.
그때문에 gnome나 kde역시 쉘이라고 보고있습니다.

펄이란걸 써보지는 않았지만 php같은 서버사이드 스크립트가 아니었나 생각됩니다. 개인적인 생각이지만 서버사이드 스크립트라는건 쉘과커널사이보다는 서버애플리케이션이 아닌가 싶군요. 다시말해 APP쪽에 가깝다고 생각합니다.

cygwin1.dll는 API의 속성을 가졌다고 생각하기엔 조금그렇다는생각입니다.
단지 배포본에 따라다니는 그런파일정도일뿐이니 API계층에서 돈다고하기보다는
APP계층에서 msvcrt.dll 같은역할만할뿐이라고 생각합니다.

B라는 쉘이 또다른A라는 쉘위에서 돌게되면 당연히 A라는 쉘의 영향을 안받을수가 없죠
특히 윈도우에서는 더욱그러는거같습니다.

유닉스에서 콘쉘이니 배쉬쉘이니 하는것은 어차피 한개의 CUI쉘이존재하고
그위에서 각각의 특징을 지어주는게 콘쉘이니 배쉬니하는걸로 알고있습니다.
gnome와 kde같은 gui쉘처럼 무거운덩어리들이 서로 독립적인형태를 가지는것같은
그런게 아니라고 생각합니다.

제가 생각하는 쉘의개념은
콘쉘, C쉘등은 하나의 공통된 API를 사용하고 그것을 사용하는 서로다른 형태의 이름인
콘쉘과 C쉘이 있고

역시 X윈도우도 쉘로서 보고있습니다. 또 Gnome나 kde역시 쉘로 보구요.
꼭 커널과 직접통신을 하는게 쉘이아니라. 자신만의 API를 가지고 그위에서 APP를 돌릴수있게
하는 모든것을 쉘로보고있습니다.

그런게 대충뚜들어맞다고 생각한다면 Cygwin역시 쉘이 아닐까요?
자신만의 API를 가지고있고 자신위에서 APP들이 돌수있다고 생각한다면 말입니다.

뭐 꼭 이게 맞는다는게 아닙니다. 제가 틀린생각을 가졌다면 이번기회에 정정을 하는게 바람직하다고
생각해서 나름대로 저의 생각을 적어봤습니다. ^^;

인간 -> 쉘(명령해석기->API) -> 커널

APP가 구동되면 쉘의 API와 바로 통신을 한다고 생각합니다.

인간-> APP->API->커널

그렇다면 드라이버는 커널쪽에 가깝다고 봐야하는건지 아니면 API쪽에 가깝다고 해야할련지..
갈수록 궁금해지는 개념들..
참고로 포팅레이어라는건 정확히 어떤개념인가요?
워낙 파생어들이 많아서리 그때그때 의도한뜻을 안물어보면. 180도 바꿔지는게 전산용어라설..

------------------------------------
F/OSS bless you... ^^*

pynoos의 이미지

dummy999님께서 사용하시는 쉘의 개념은 쉘이라기보다는 하나하나가 계층(layer)라 생각되는군요.

대개 프로토콜이나 새로운 개념의 Library가 나오게 되면, 계층(Layer)이라는 표현으로 그 구성도를 그리게 됩니다.
예를 들면, WAP, WDM Drivers, SSL 등등 문서를 보게되면, 그들이 구성되어 있는 library stack 또는 프로토콜 stack 들이 있게 됩니다.
이들 계층이 내부에서 동작하느냐 또는 외부로 나와 사람의 직접적인 조절하에 있느냐에 따라 의미상 쉘이니 API 니 Application이니 하는 이름으로 나오게 됩니다.

보통 설계에서 각 계층은 위 아래 개념이 추상화되어 독립성/확장성등을 고려하며 만들어지게 됩니다. 제가 말한 포팅 레이어는 이런 어플리케이션들이 동작하는데 사용하는 개념상 포팅을 하기 위한 API 계층을 말하는 것입니다.

Quote:
유닉스에서 콘쉘이니 배쉬쉘이니 하는것은 어차피 한개의 CUI쉘이존재하고
그위에서 각각의 특징을 지어주는게 콘쉘이니 배쉬니하는걸로 알고있습니다.
gnome와 kde같은 gui쉘처럼 무거운덩어리들이 서로 독립적인형태를 가지는것같은
그런게 아니라고 생각합니다.

한 개의 공통된 CUI (CLI)가 존재하는 것은 아닙니다. 각각은 gnome, kde 만큼 다른 녀석들입니다.

cjh의 이미지

shell이라고 하면 일반적으로 커널과 사용자간 인터페이스라고 생각할 수 있습니다. 보통 연상하는것이 윈도우의 쉘(explorer)나 csh, sh이라고 생각하시면
대충 맞는 것이겠죠.

cygwin은 다른 분이 지적하셨듯이 cygwin1.dll로 이름지어지는 unix
레이어와 이걸 기반으로 컴파일된 각종 GNU/nonGNU 유틸리티군입니다.
cygwin1.dll만 말하자면 "Win32상의 UNIX함수를 쓰기 위한 라이브러리"
이고 관련 도구까지 한꺼번에 말하면 "Win32상의 유닉스 호환 플랫폼"
입니다. 즉 Win32 플랫폼 상에서 Unix 플랫폼(GNU에 가깝습니다만)의
프로그램을 컴파일하여 직접 실행하고자 하기 위한 중간 계층(다른분은
포팅 레이어라고 했는데 그 표현이 적당한 것 같네요)이 되는 것입니다.

cygwin 배포본 안에도 각종 쉘이 포함되어 있습니다만 그것만으로
cygwin을 나타내기는 어려울 것 같네요. 반대로 유닉스 상의 wine이 어떠한
위치에 있는지 생각해 보시면 좋을것 같습니다.

dummy999 wrote:
cygwin을 종류로 구분지어야할때 이것을 정확히 어떤장르에 넣어야 좋을까요?
에뮬레이터라고 해야할지 아니면 그냥 유틸리티일련지 아니면 또다른쉘이라고 해야할지..
왜냐면 cygwin은 그만큼 모호성이 있어보이기때문입니다.
저는 이게 쉘쪽에 가깝다고생각합니다.
어떤쉘이든간에 커널과 통신을 하고 그기반에서 APP를 돌리기때문에
그런속성을 cygwin은 만족하고있다고 생각하기때문입니다.

아울러 이건 질문인데 걍 쓰는김에 같이 쓸께용.
cygwin에서 linux_logo라는 프로그램을 돌릴려고하는데 이걸쓰려면 glibc가있어야합니다.
이것이 뭐하는 라이브러리이며 또 cygwin용에서 돌릴려면 어디가서 받아야하는지
궁금합니다.

참고로 첫질문은 철학적인개념이 있을꺼같아서 여기에 넣습니다.
두번째 질문은 꼽사리입니다. 그래도 두번째 질문에도 답좀 해주세용 ^^;

--
익스펙토 페트로눔

Prentice의 이미지

dummy999님께서 말씀하신 내용에는 어느 정도 공감을 합니다만, 사용하신 논리에 대해서는 선뜻 동의하기 힘드네요.

시그윈과 셸이 공통점을 가진다고 해서 시그윈이 셸이 되는 것은 아니라고 생각합니다. 공통점이 있다면 부분집합도 될 수 있는 것이고 상위집합도 될 수 있는 것이죠. 아니면 그냥 교집합이 있는 다른 집합일 수도 있고요. 저는 개인적으로 시그윈을 POSIX layer로 보는 쪽 사람입니다.

저는 또한 커널은 프로세스들의 운영의 내부 세부 사항을 관장하는 프로세스, 셸은 프로세스의 시작과 종료등을 사용자의 명령에 따라 관장하는 프로세스로 생각하고 있습니다. 프로세스는 "현재 CPU가 메모리로 불러와 실행하고 있는 바이너리"로 생각하고 있습니다. 바이너리는 기계어로 되어 있는 프로그램이라고 생각하고 있고요.

notexist의 이미지

홈...근본적으로 용어의 정의 문제라고 생각합니다...

이런 토론,토의를 할때는 일반적으로 사용되는 의미로 단어를 사용해야된다고

생각합니다.

A라는 것에 대해서 '가'라는 사람은 B라고 정의를 하고 '나'라는 사람은

C라고 정의를 하고 서로 토론을 하면 답이 나올리 없습니다.

------------------------------------------------------------------------------------
쉘은 유닉스에서 대화형 사용자 인터페이스를 부르는 용어이다. 쉘은 사용자가 입력하는 명령어를 이해하고, 실행하는 역할을 수행한다. 시스템에 따라서는 쉘을 명령어 해석기라고 부르는 경우도 있다. 쉘은 보통 명령어 문법에 맞추어 이용하는 인터페이스를 가진다
<= 일반적으로 대부분은 이렇게 생각합니다.

dummy999 wrote:

참고로 제가 개념을 잡고있는 레이어는 다음과같습니다.
한가지 일(계획(인간(인간->..->인간)->sw(app -> 쉘->..->커널->..)->HW(머신->..->머신)) ->행동(작업결과))
보기가 복잡합니다. 어디에도 안나와있는거같더라구요.

모든 것은 정의하기 나름이지만...
본인의 개념이 보기 복잡하고, 어디에도 안 나와있는 것같으면...
스스로 다시 한번 생각을 해보시는 것이 좋을 듯합니다...

일반적으로 dummy999님의 셸은 layer(계층)이라는 단어로 표현됩니다.

There is more than one way to do it...

dummy999의 이미지

제가 말하는 분류라는것은 계층적인 분류를 의미했습니다.
당연히 그럴꺼다라고 생각하고 말했는뎅..

참 제가 무식하게도 포직스라는것의 정확한어원을 잘몰랐습니다.
뭐 지금도 마찬가지지만 제가 지금까지 정보수집한지 얼마안된상태에서
나름대로 개념을 정의하라 한다면 포직스 레이어라는것은
일종의 인터페이스의 한종류라고 볼수있겠습니다.

제가 아는분에게 물어도 보고했는뎅 포직스나 미들웨어나 하는역할은 비슷하다고생각합니다.
어차피 둘다 다른객체에 영향을 주지않고 객체간의 통신에서 서로 변환만해주는격이니까요.
개인적으로 이런미들웨어틱한것들을 좋아라합니다.
참. 그리고 이런것들을 아는분에게는 미들웨어가 상위개념이아닌가라고 물어봤는데
모강사님께서 인터페이스아래 미들웨어나 포직스의 개념이 들어간다고하더라구요.
(알고그런건지 모르고그런건지 몰겠지만. 좀더 추상적이고 넓은 의미로서의 인터페이스는
적절한 분류였다고 생각합니다.)

인터페이스>미들웨어>포직스
인터페이스는 객체간의 통신할때 쓰는 규약을 의미하는 추상적인단어이고
(system이라는뜻처럼)
미들웨어는 이를 소프트웨어적인기술로 구현해놓은 소프트웨어를 미들웨어라고 하고
포직스는 그런 구체적인 형태를 의미한다고 생각합니다.
이것을 객체지향에서는 분류(Classification)이라고 하던데.. 이분류가 적절한지.. ^^;
그리고 전산용어는 상당히 주관적인게 많습니다. 대부분은 그런분류에대한 개념을 적용하지않고
무작정 만들어버리는경우가 있는데 외국사람들 특징이라더군요..
울나라사람들은 이름을 지어도 뭔가 의미있게 짓는데비해 상당히 (개인적으로는)건방져보이는
태도같습니다.(무성의하다고 해야하나?)
자바를 막무가네로 이름을 지어버리다니.. 그래도 울나라같았으면 작명소에다 물어보고
투표까지했을지도 모를일이었지만..

아 잠시 삼천포로 빠졌당 -_-;;
궁금한게 BlackSun님은 CygWin이 포직스계층이라고 하고 위에 분들 몇부은포팅계층라고하는뎅
또 저는 쉘계층이라고 하니 ..

근데 저는 어차피 CygWin에도 APi가 (물론 Cygwin전용은 아니지만)있고 자체적으로 그기반에서
APP를 돌릴수있다고 보고 또 쉘이 쉘을 호출하는일은 얼마든지 가능한일이라는것을
유닉스에서는 보여주고있기때문에 저는 암만봐도 쉘이되지않을까하는 생각이 지배적입니다.

물론 어떤 플그램들도 자체적인 라이브러리(API)들이 있긴하지만 범용라이브러리는 아니고
또 이런것들을 보면 애플릿(작은 프로그램조각:: 여기서는 프로그램파일들.. doc파일이나
엑셀파일 또는 플래시 파일같은 그런유형, 이것들은 전용APP위에서 돌게된다.)
을 돌릴수있다는점에서 APP도 작은쉘이라고 볼수있을겁니다.

그러나 저는 그런모호함에서 가장중요한 쉘의 특징이라고 생각한다면
자체적인 명령어해석기와 API를 구성요소로가지고있고 쉘은 커널, 인간사이에서 중계역할을 하며
통신을 한다고 생각합니다. (물론 다른쉘과도 통신이 가능도하겠지만)

그리고 개인적인생각인데 포팅레이어라하는것은 cygwin1.dll이나msvcrt.dll 들등이
포팅레이어역할을 하는녀석들같은뎅..

- 아무튼 개념잡는데 이번이기회라고 생각합니다.

------------------------------------
F/OSS bless you... ^^*

정태영의 이미지

Quote:
참 제가 무식하게도 포직스라는것의 정확한어원을 잘몰랐습니다.
뭐 지금도 마찬가지지만 제가 지금까지 정보수집한지 얼마안된상태에서
나름대로 개념을 정의하라 한다면 포직스 레이어라는것은
일종의 인터페이스의 한종류라고 볼수있겠습니다.

POSIX는.. '다른 OS로 이식 가능한' 이란 뜻입니다 =3=33

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

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

hey의 이미지

쉘에서 다른 프로세스를 실행한다고 해서 쉘이 그 프로세스와 커널 사이의 가교 역할을 하는 것은 아닙니다. 위의 여러 분들이 설명해주셨다시피 쉘은 사용자의 명령을 해석하는 역할만을 합니다.

cygwin 패키지에는 POSIX 포팅 레이어인 cygwin1.dll을 사용하도록 컴파일 된 여러 바이너리들이 들어 있습니다. (아마)
dummy999님은 cygwin을 쉘이라고 생각하시지만, 실제로는 cygwin 패키지 안에 여러 바이너리 중의 하나로 쉘이 들어 있는 것뿐입니다.

cygwin는 해당 라이브러리를 사용하기만 하면 POSIX 규격에 따라 짜여진 바이너리를 (POSIX를 지원하지 않는)win32에서 실행할 수 있도록 돕는 한 단계의 레이어입니다. 그래서 POSIX 계층 또는 포팅 레이어라고 부르시는 거구요. (같은 말입니다)

그리고 쉘에서 X를 실행한다고 해서 X가 쉘을 통해서 커널과 통신하는 것은 아닙니다. 하지만 GNOME 프로그램은 GTK 라이브러리를 사용하고 GTK는 XLIB을 사용하죠. 그러나 이런 단계를 쉘이라고 부르지는 않습니다. 왜냐하면 쉘은 다른 용어로 쓰이기 때문이죠. 이것은 그저 레이어나 계층이라고 부르면 족합니다.
윈도우의 익스플로러는 쉘의 역할을 하는 프로그램입니다만 익스플로러에서 프로그램을 실행한다고 해서 그 프로그램이 익스플로러를 통해 NT 커널과 일하는 것은 아닙니다.

dummy999님이 사용하신 단어들을 그렇게 사용하고 싶다면 뭐라고 할 말은 아닙니다만, 이미 다른 곳에서 사용되고 있는 단어들을 다른 용도로 사용하시면 서로간에 전혀 이야기가 되지 않을거라는 사실은 알고 계시는 편이 좋겠습니다.
맘에 안들면 혼자 사용하기 전에 공론화해서 다른 사람을 먼저 설득하셔야지요.


----------------------------
May the F/OSS be with you..


hey의 이미지

dummy999 wrote:
쉘자체는 단지 APP를 실행할수있게하는 실행기일뿐 계층도로봤을때 APP가 실행될때
쉘을 의존하지않을꺼라생각합니다.

이 말씀이 사실이라면

dummy999 wrote:

다시말하자면 <인간-APP-쉘-커널-머신-작업> 이쪽레이어에서는 끼어줄 틈이 없죠.

이 관계는 사실이 아닙니다. 프로그램은 쉘에 의존하지 않는다고 말씀하셨지요. 그려주신 그림은 다음과 같지만 순서가 달라서 참조하지 않겠습니다.

dummy999 wrote:

  인간
    쉘
      APP
        커널
          머신
            작업

포팅 레이어는 프로그램과 커널 사이에 들어갈 겁니다. 이것은 기존에 없는 특별한 단계를 가정하지 않더라도 우리가 보통 라이브러리를 사용하는 것과 마찬가지로 생각하면 됩니다.

dummy999 wrote:

그리고 제가 Cygwin이 쉘이라고 확신하는것은 님들이 말하는 포팅레이어가 포함되어있기때문이죠
그리고 포팅레이어는 그자체가 계층에 해당된다고 생각하진않습니다.

이것들은 거의 90%이상은 필수적 요소들로 이뤄지는 레이어들입니다.
여기서는 포팅레이어라는게 그다지 필수적인요소는 아닙니다.
그것은 APP나 쉘보다는 사용빈도가 낮은걸로 알고있습니다.
다시말하자면 <인간-APP-쉘-커널-머신-작업> 이쪽레이어에서는 끼어줄 틈이 없죠.

비록 dummy999님께서 위와 같이 말씀하셨음에도 불구하고, 사실 cygwin을 사용한다고 말하는 것은 쉘보다는 POSIX 계층을 뜻하는 것이 더 활용도가 많을 겁니다.
우리가 cygwin을 사용하면 win32에 대해서는 생각할 필요 없이 POSIX 규약에만 따라서 프로그램을 만들어 윈도우에서 실행시킬 수가 있습니다. 그래서 기존에 유닉스용으로 만들어진 프로그램을 윈도우로 포팅할 때 cygwin을 사용하는 겁니다. 말씀하신 여러 프로그램들도 그런 방식으로 포팅되어서 패키지에 같이 포함되어 있는거구요.

dummy999 wrote:

제가 꼭 말해주고싶은건 위의 계층에는 어디에도 포팅레이어가 없다는겁니다.
저계층도는 저나 또는 다른 모든전산을 배운분들이라면 다 아는 일반적인 계층분류입니다.
그리고 우리는 그것을 지금까지 신뢰해왔습니다.

Cygwin은 포팅레이어라는게 필요로하는건 위분들이 말씀해주신대로일겁니다.
cygwin은 위의 계층도에서 그계층에속해야한다면 쉘쪽에 가깝다고 보는편이좋고
포팅레이어라는것도 cygwin에서는 무시할수없는 요소이므로
반드시 끼워넣어야한다면 그것은 쉘에 내포할수있다라고 보고싶습니다.
그러면서도 다른쉘들이 가지는 모든 속성을 가지기때문에 쉘이라고 보고있습니다.
다른쉘에비하면 약간의 통합적인 쉘개념이라고 생각합니다.

마찬가지로 JVM역시 그계층도를 봤을때 포팅레이어라는것은 어디에도 기술되지않았습니다.
그렇지만 JVM자체가 그런것을 속성으로 내포하고만있습니다.

어차피 cygwin에서 포팅레이어라는것은 단순하게 파일하나가 그역할을 해주고있는걸로 알고있습니다.
그리고 포팅레이어라는것은 기본레이어에서 필수라고 생각하지않습니다. 그렇기때문에
필요로하지만 기본(거의 필수적인요소)에는 속하지않으므로 기본적인 구성요소에 끼워넣기를
하면 그공식은 성립한다라고 생각합니다.

그렇기 때문에 dummy999님이 이 말씀은 알맞지 않은 것 같습니다.
오히려 그 단순한 파일 하나가 필수적인 것이며, 나머지 것들은 그걸 이용해서 POSIX 유틸리티들을 포팅한 것에 지나지 않습니다. dummy999님이 중요하게 생각하시는 쉘도 그런 유틸리티 중의 하나이구요.

dummy999 wrote:

위에 글써주신분들의 말씀이 틀리다는게 아닙니다.
단지 쉘이라는것에 포팅레이어는 필수가 아니기때문에 제가 그점에대해 말하고있는거고요.

어디에서는 위의 계층도에서 쉘이라는개념대신 APP라는 개념을 사용하고있었습니다.
그말도 상당히 설득력이있었습니다.
모든APP는 각자의 라이브러리를 가질수도있고 또 또다른 APP를 로딩시킬수있다는점에서
쉘과 그속성이 상당히 유사합니다.
그런데도 저는 위에다 APP와 쉘을 같이 써놨는데 대부분은 그렇게 알고있기때문에
일반적인형태로 글을 쓴겁니다.
뭐 저역시 "쉘이나 APP나"라는말을 하고싶습니다. 어차피 JVM역시 APP에속하고 그것도
그안에다 포팅레이어를 끼워넣을수있을수있으니까요..

참.. 지금제가 글을 쓴건 수직적인 구조인데 만약 APP의 기능을따지는 장르로 구분했을때
쉘이라는 개념보다는 cygwin1.dll이라는것이 중요하므로 이때 쉘계열에 포함되는 포팅 레이어

라이브러리들역시 쉘계층에속하는(또는 포함하는)API류라고 보는편이 좋을듯하구요.
그리고 압축플그램같은건 유틸리티APP에서압축app류에 속한다라고 생각합니다.

APP- 쉘      
   - 유틸리티(압축,       파일,  액세서리, 기타..)
   - 게임    (rpg, sml, act, adv, puz, ...)
   - 편집기  (스프레드쉬트, 프리젠테이션,캐드프로그램, 소리편집프로그램)
   - 서비스  (웹서버, FTP서버, 파일서버, APP서버)

<<쉘의 계층구분>>

 명령어해석기
  API
 포팅레이어(선택적요소)


(순서는 어떤게 먼저인지 잘몰겠음)

최종적인 제생각이니만큼 여기서 틀렸다면 수정할필요가 있다고 생각합니다.

재차 말씀드리지만 포팅 레이어는 쉘에 속하는 것이 아니고 반대로 그 쉘이라는 프로그램이 포팅 레이어를 통해 윈도우에서 돌아가고 있는 것입니다.


----------------------------
May the F/OSS be with you..


hey의 이미지

어라, 제가 인용해서 답변을 달던 글이 없어졌네요.
또 금방 새로운 글을 올려주시리라 믿습니다.


----------------------------
May the F/OSS be with you..


dummy999의 이미지

아이.. 위에꺼 다지우고 다시썼는뎅 그사이에 글을써놔버렸네용.. ㅡ.ㅡ;;
여튼 좀중복성이 있어보이는뎅 저는 위에꺼 글안읽어본상태에서 이글썼습니다.
이글쓰고 읽어봐야겠네용

<<일반적인 레이어표현>>
  인간
    쉘
      APP
        커널
          머신
            작업

이것들은 거의 90%이상은 필수적 요소들로 이뤄지는 레이어들입니다.
여기서는 포팅레이어라는게 그다지 필수적인요소는 아닙니다.

<<APP의 구분 표현>>
APP- 쉘      
   - 유틸리티(압축,       파일,  액세서리, 기타..)
   - 게임    (rpg, sml(시뮬레이션), act(액션), adv(어드벤쳐), puz(퍼즐), ...)
   - 편집기  (스프레드쉬트, 프리젠테이션,캐드프로그램, 소리편집프로그램)
   - 서비스  (웹서버, FTP서버, 파일서버, APP서버)

여기서 서비스APP라는것은 머신을 말하는게 아니라 단지 APP단위의 프로그램을 말합니다. (혹시나 서버머신으로 오해할사람이있을꺼같아서 미리 말했음돠.
저는 그렇게 생각안하는데 그런분들이 있긴있더라구요 8) )
게임장르는 예전 90년대 중반 게임분류를 근거로 했습니다.

<<쉘의 계층구분>>

 명령어해석기
 API
 포팅레이어(선택적요소)


(순서는 어떤게 먼저인지 잘몰겠음)

<< 포팅레이어의 계층 : 아래로 내려갈수록 구체화되고 위로 올라갈수록 추상적임>>
인터페이스  : 객체간의 통신할때 쓰는 규약, 범용적인 용어
  포팅레이어  : 인터페이스의 전산적인 용어(개념적임)
    미들웨어    : 통신규약을 소프트웨어적으로 구현한것
      포직스      : IEEE와 스톨만이 지어놓은 구체적인 규약들
      RMI         : 자바에서쓰는 분산처리의 미들웨어류?
      (기타)      : 그런게 있다고요.. :D 

같은텝에 있는것은 같은 레벨이라고 생각해서 분류했습니다.

길게 글로 안쓰고 표로 보일수있게 다시썼구요.
최종적인 제생각이니만큼 여기서 틀렸다면 수정할필요가 있다고 생각합니다.
근데 cygwin1.dll이 포팅레이어의 일종이라면 msvcrt.dll의 분류는 어떻게 될련지..
이넘은 포팅레이어라고 하기엔 거리가 멀지않을까하는뎅..

hey님의 말씀이 맞다면 APP안에 포팅APP라는 분류가 필요로하지않을까합니다.
쉘안에 들어가지않는다면말입니다.
뭐 꼭 제가 맞는다고 생각해서 그렇게 뽀샤시하게 쓴건아니에영.
그리고 이런포팅레이어는 쉘을 포함한다라고 보는게 옳겠군요.
hey님의 생각이 틀린말은 아닐꺼같다는 생각이 듭니다.

참고적으로 위에 글썼다가 지워버렸는뎅 APP들은 서로다른 APP와 통신을 합니다.
그게 제가 말했던거들처럼 쉘과 비슷한 역할을 하기때문에 APP에 쉘이 속한다고 생각했습니다.
어디서는 아예 쉘이라는 개념자체를 없애버렸더라구요.
쉘이나 APP나 거기서 거기였다라고 하는분들이 많던데 최근에와서 공감하는 바입니다.
진짜로 알고 그런말했는지는 몰겠지만. 그래도 뭔가 맞다고 생각도 됩니다.

----------------------------------------------
솔직히 따분하지않는 탁상공론이라고 생각합니다.
그만큼 얻어가는게 있고 그것은 귀중한 지식이라생각하니까요.
뭐 첨엔 토론부분에다 글을 쓸까했는뎅 웬지 거기엔 딱딱한느낌이들어 여기다 글을썼습니다.

------------------------------------
F/OSS bless you... ^^*

hey의 이미지

dummy999 wrote:

<<쉘의 계층구분>>

 명령어해석기
  API
 포팅레이어(선택적요소)


(순서는 어떤게 먼저인지 잘몰겠음)

제가 좀 기다릴 걸 잘못했네요. 지금 여러 분들의 의견을 모아서 정리를 하고 계신 것 같은데 혼동이 좀 있으신 듯 합니다.
간단히 api나 포팅 레이어가 쉘에 포함된다는 생각만 하지 않으면 간단히 정리될 겁니다.

POSIX는 여러 가지 OS가 난립하면서 각각 다른 표준으로 만들어져 프로그램이 공유될 수 없는 상황을 막기 위해(아마) 제시된 OS 표준 규약입니다. POSIX는 유닉스의 구조를 기반으로 하고 있으며, 이후에 만들어지는 OS들은 POSIX를 대부분 잘 따르고 있습니다.

그런데 아시다시피 윈도우는 POSIX 규약을 따르지 않는 OS이고, POSIX를 기준으로 만들어지는 많은 프로그램은 당연히 윈도우에서 돌지 않습니다. 그래서 우리는 해당 유틸리티들을 윈도우로 포팅하고 싶습니다. 그런데 그러기 위해서는 win32 api와 생소한 디렉토리 구조 등을 새로 배워야 합니다. 단지 윈도우라는 OS 하나만을 위해서요. 아마 포팅 레이어가 있으면 이 일을 쉽게 해결할 수 있을겁니다. 그래서 cygwin이라는 레이어를 POSIX 기반에서 만들어진 프로그램과 WIN32 사이에 끼워 넣습니다.

그러니까 이 포팅 레이어라는 계층은 이와 같은 '특수한 경우'에만 필요한겁니다.그런데, cygwin은 바로 이 일을 합니다. 그래서 포팅 레이어는 cygwin의 거의 전부라고 할 수 있습니다.

dummy999 wrote:

<< 포팅레이어의 계층 : 아래로 내려갈수록 구체화되고 위로 올라갈수록 추상적임>>
인터페이스  : 객체간의 통신할때 쓰는 규약, 범용적인 용어
  포팅레이어  : 인터페이스의 전산적인 용어(개념적임)
    미들웨어    : 통신규약을 소프트웨어적으로 구현한것
      포직스      : IEEE와 스톨만이 지어놓은 구체적인 규약들
      RMI         : 자바에서쓰는 분산처리의 미들웨어류?

같은텝에 있는것은 같은 레벨이라고 생각해서 분류했습니다.

길게 글로 안쓰고 표로 보일수있게 다시썼구요.
최종적인 제생각이니만큼 여기서 틀렸다면 수정할필요가 있다고 생각합니다.
근데 cygwin1.dll이 포팅레이어의 일종이라면 msvcrt.dll의 분류는 어떻게 될련지..
이넘은 포팅레이어라고 하기엔 거리가 멀지않을까하는뎅..

인터페이스-포팅레이어-미들웨어 등은 크게 보면 비슷한 뜻이라고 볼 수 있습니다. 하지만 모든 비슷한 용어들이 전부 그렇게 계층적으로 이루어지는 것은 아닙니다. 그리고 이 쓰레드에서 포팅 레이어라고 부르는 것은 'cygwin의 위치를 굳이 구분하자면 아마 포팅 레이어쯤 될 겁니다' 라는 수준의 이야기이지 포팅 레이어라는 계층이 개념적으로, 명확히, 어딘가에 있다는 얘기는 아닙니다.


----------------------------
May the F/OSS be with you..


정태영의 이미지

dummy999 wrote:
아이.. 위에꺼 다지우고 다시썼는뎅 그사이에 글을써놔버렸
<<쉘의 계층구분>>

 명령어해석기
 API
 포팅레이어(선택적요소)


맞습니다.. 쉘은 명령어 해석기입니다..
cygwin이 없이는..윈도우에서 POSIX를 준수하는 프로그램들을 컴파일하고 돌릴 수 없습니다..

cgwin은 윈도우에 존재하지 않는.. POSIX관련 함수들을 사용할 수 있게 해주는
일종의 라이브러리인 셈이지요 =3=33

그리고 위에 다른 분이 써놓으셨듯이.. cygwin을 통해서..
bash같은것들을 윈도우에서 돌릴 수 있도록 컴파일해서 포함해 놓은 거죠..

그게 cygwin의 정체 입니다..

리눅스는 커널입니다.. 단지 커널이죠..
하지만 사람들이 통칭으로 사용하는 리눅스는 커널이 아닌..

리눅스라는 커널을 사용하는 배포판을 말합니다..

그것과 비슷하게
cygwin은 POSIX를 윈도우에서 사용할 수 있게 해주는 포팅 레이어입니다..

하지만 dummy님이 생각하시는 cygwin은 cygwin자체가 아닌..
cygwin을 이용해서 컴파일해서 같이 패키징해놓은..
그것이겠죠..

cygwin을 설치하실때 좀 더 주의깊게 보시면..
여러가지 패키지들을 설치하는 걸 알 수 있을겁니다..

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

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

dummy999의 이미지

제 생각인데 만약 포팅레이어가 필수적인 요소라고한다면 쉘에끼워져있어야겠지만
그렇게했을때 리눅스에서 BAsh나 Csh등의 기타쉘에겐 상당히 성능저하로 나타날껍니다.
포팅레이어가 APP의 한종류라고 한다면 포팅레이어라는 말보다 다른말이 더어울릴꺼같습니다.

그리고 CygWin말고도 이와 비슷한 것들이 또 존재하는지 찾아봐야지 분류에 속할수도있을껍니다.
wine ?

몇가지 수정부분입니다.

<<APP의 구분 표현>> 
APP- 쉘      
   - 유틸리티(압축,       파일,  액세서리, 기타..) 
   - 게임    (rpg, sml(시뮬레이션), act(액션), adv(어드벤쳐), puz(퍼즐), ...) 
   - 편집기  (스프레드쉬트, 프리젠테이션,캐드프로그램, 소리편집프로그램) 
   - 서비스  (웹서버, FTP서버, 파일서버, APP서버) 

이것을 아래처럼 고치면 되겠네요.

<<APP의 구분 표현>> 
APP- 쉘      
   - 유틸리티(압축,       파일,  액세서리, 기타..) 
   - 게임    (rpg, sml(시뮬레이션), act(액션), adv(어드벤쳐), puz(퍼즐), ...) 
   - 편집기  (스프레드쉬트, 프리젠테이션,캐드프로그램, 소리편집프로그램) 
   - 서비스  (웹서버, FTP서버, 파일서버, APP서버) 
   - 포팅레이어 

그리고 포팅레이어의 기능은 쉘을 집어삼켜 그쉘이 못사는 척박한곳에서도 마치 자기집처럼
환각작용을 일으켜주는 그런 프로그램이라고 보는게 좋겠군요..
---------------------------------------------------------------

<<쉘의 계층구분>>

 명령어해석기
 API
 포팅레이어(선택적요소)

이것은 아래처럼..

<<쉘의 계층구분>>

 명령어해석기
 API

---------------------------------------------------------------

<< 통신개체의 계층 : 아래로 내려갈수록 구체화되고 위로 올라갈수록 추상적임>> 
인터페이스  : 객체간의 통신할때 쓰는 규약, 범용적인 용어 
  포팅레이어  : 인터페이스의 전산적인 용어(개념적임) 
    미들웨어    : 통신규약을 소프트웨어적으로 구현한것 
      포직스      : IEEE와 스톨만이 지어놓은 구체적인 규약들 
      RMI         : 자바에서쓰는 분산처리의 미들웨어류? 

여기까지봤을때 포팅레이어라는게 두곳에서 쓰입니다. 하나는 통신개체의 계층도에서
포팅레이어이고 다른하나는 APP분류에서 포팅레이어인데. 분명 두개는 개념상차이가 있습니다.
cygwin은 둘중하나를 의미하는것이기때문에
포팅레이어라는말이 맞다면 cygwin은 APP에 속하지않고
계층에서 포팅레이어라는 말이 맞다면 cygwin은 포팅레이어라는말보다는 다른용어로서써야할껍니다.

솔직히 첨부터 레이어라는말을 APP단위에서 쓴다는게 어색합니다.
(감히 APP따위가 레이어라는 호칭을 달수있다게 말이안된거같다는 봉건적인 생각이..)
분명히 레이어는 상위적인 개념으로 구체적인 형태인 Cygwin에게는 적절한 표현은 아닙니다.

제생각에는 개체계층에서 포팅레이어라는 말을빼버리고 APP에속하면서 포팅레이어라는말보다는
다른 용어가 훨씬 더 적절하지않을까합니다.

예컨데 Foreign Environment Portting,포팅프로그램, 포팅이라던지...
마치 유틸리티레이어라는거처럼 상당히 거부감이 듭니다.
처음부터 cygwin이 레이어라는단어가들어간게 좀 그렇다는생각이 들었기때문에 이것을
다른분류로서 레이어라는 말은 빼는게 좋겠다는생각이 듭니다.
그래서 cygwin을 쉘로보자고 했던거같음
용어정리하다보면 단어에 상당히 민감해집니다.

------------------------------------
F/OSS bless you... ^^*

Prentice의 이미지

그런데 시그윈의 포팅 레이어를 app 실행하듯이 셸에서 실행할 수 있는 건 아니잖아요. 프로그램이나 app의 하부개념으로 분류하신 것은 문제가 있지 않을까요?

hey의 이미지

dummy999 wrote:
제 생각인데 만약 포팅레이어가 필수적인 요소라고한다면 쉘에끼워져있어야겠지만
그렇게했을때 리눅스에서 BAsh나 Csh등의 기타쉘에겐 상당히 성능저하로 나타날껍니다.

아까도 말씀드렸지만 포팅 레이어는 '특수한 용도'로 사용됩니다. POSIX를 준수하는 OS가 아닌 OS로 포팅하기 위해 포팅 레이어가 필요한겁니다. 반대로 POSIX를 준수하는 OS에서는 당연히 포팅 레이어가 필요하지 않습니다.

지원하지 않는 것을 지원하려고 하니까 당연히 성능 저하가 나타납니다.

dummy999 wrote:

포팅레이어가 APP의 한종류라고 한다면 포팅레이어라는 말보다 다른말이 더어울릴꺼같습니다.

실행되는 프로그램을 레이어라고 부를 이유가 없습니다. dll이 무슨 파일인가요? 라이브러리입니다. POSIX 유틸리티와 비 POSIX OS 사이에 들어가는 라이브러리이므로 당연히 포팅을 위한 것이며, 포팅 레이어라고 부를 수 있을 겁니다.

dummy999 wrote:

그리고 CygWin말고도 이와 비슷한 것들이 또 존재하는지 찾아봐야지 분류에 속할수도있을껍니다.
wine ?

몇가지 수정부분입니다.

<<APP의 구분 표현>> 
APP- 쉘      
   - 유틸리티(압축,       파일,  액세서리, 기타..) 
   - 게임    (rpg, sml(시뮬레이션), act(액션), adv(어드벤쳐), puz(퍼즐), ...) 
   - 편집기  (스프레드쉬트, 프리젠테이션,캐드프로그램, 소리편집프로그램) 
   - 서비스  (웹서버, FTP서버, 파일서버, APP서버) 

이것을 아래처럼 고치면 되겠네요.

<<APP의 구분 표현>> 
APP- 쉘      
   - 유틸리티(압축,       파일,  액세서리, 기타..) 
   - 게임    (rpg, sml(시뮬레이션), act(액션), adv(어드벤쳐), puz(퍼즐), ...) 
   - 편집기  (스프레드쉬트, 프리젠테이션,캐드프로그램, 소리편집프로그램) 
   - 서비스  (웹서버, FTP서버, 파일서버, APP서버) 
   - 포팅레이어 

그리고 포팅레이어의 기능은 쉘을 집어삼켜 그쉘이 못사는 척박한곳에서도 마치 자기집처럼
환각작용을 일으켜주는 그런 프로그램이라고 보는게 좋겠군요..

cygwin이라는 포팅 레이어의 기능은 비 POSIX OS인 윈도우를 POSIX OS인 것처럼 코딩을 해도 컴파일 될 수 있도록 돕는 것입니다. 쉘뿐만 아니라 다른 프로그램에게도 마찬가지로 역할을 할 것입니다.

dummy999 wrote:

---------------------------------------------------------------
<<쉘의 계층구분>>

 명령어해석기
 API
 포팅레이어(선택적요소)

이것은 아래처럼..

<<쉘의 계층구분>>

 명령어해석기
 API

쉘은 명령어 해석기 입니다만, 프로그램에게 API를 제공하지는 않습니다. 사용자가 입력한 명령을 해석해서 다른 프로그램을 실행해 주는 것입니다. 포팅 레이어도 쉘에 속하지 않고, API도 쉘에 속하지 않습니다.

dummy999 wrote:

---------------------------------------------------------------

<< 통신개체의 계층 : 아래로 내려갈수록 구체화되고 위로 올라갈수록 추상적임>> 
인터페이스  : 객체간의 통신할때 쓰는 규약, 범용적인 용어 
  포팅레이어  : 인터페이스의 전산적인 용어(개념적임) 
    미들웨어    : 통신규약을 소프트웨어적으로 구현한것 
      포직스      : IEEE와 스톨만이 지어놓은 구체적인 규약들 
      RMI         : 자바에서쓰는 분산처리의 미들웨어류? 

여기까지봤을때 포팅레이어라는게 두곳에서 쓰입니다. 하나는 통신개체의 계층도에서
포팅레이어이고 다른하나는 APP분류에서 포팅레이어인데. 분명 두개는 개념상차이가 있습니다.
cygwin은 둘중하나를 의미하는것이기때문에
포팅레이어라는말이 맞다면 cygwin은 APP에 속하지않고
계층에서 포팅레이어라는 말이 맞다면 cygwin은 포팅레이어라는말보다는 다른용어로서써야할껍니다.

지난 글에서도 말씀 드렸지만, 포팅 레이어라는 용어는 '~쯤 되겠다'라고 말한 것에 지나지 않습니다. 우리가 흔히 포팅 레이어라는 말을 사용할 수도 있겠지만, 그게 어딘가의 계층에 소속되거나, 뭔가를 포함하거나 하는 용어는 아니라는 말씀입니다.

dummy999 wrote:

솔직히 첨부터 레이어라는말을 APP단위에서 쓴다는게 어색합니다.
(감히 APP따위가 레이어라는 호칭을 달수있다게 말이안된거같다는 봉건적인 생각이..)
분명히 레이어는 상위적인 개념으로 구체적인 형태인 Cygwin에게는 적절한 표현은 아닙니다.

제생각에는 개체계층에서 포팅레이어라는 말을빼버리고 APP에속하면서 포팅레이어라는말보다는
다른 용어가 훨씬 더 적절하지않을까합니다.

예컨데 Foreign Environment Portting,포팅프로그램, 포팅이라던지...
마치 유틸리티레이어라는거처럼 상당히 거부감이 듭니다.
처음부터 cygwin이 레이어라는단어가들어간게 좀 그렇다는생각이 들었기때문에 이것을
다른분류로서 레이어라는 말은 빼는게 좋겠다는생각이 듭니다.
그래서 cygwin을 쉘로보자고 했던거같음
용어정리하다보면 단어에 상당히 민감해집니다.

정리하자면, cygwin 패키지 안에는 cygwin을 기반으로 컴파일 된 여러 프로그램들이 동봉되어 있으며, 그 중에는 쉘도 있습니다.


----------------------------
May the F/OSS be with you..


vacancy의 이미지

dummy999 님의 글은 늘상 이런식이네요.

질문 비슷하게 시작해서,
다른 분들이 성의있게 답변해주기 시작하면
거기에서 꼬투리 잡고 자기 의견을 내놓고
다른 사람들이 아니다, 이건 이런거다 라고 설명해줘도
거기에 계속 우기는 글을 다시고요. -_-
게다가 그다지 중요하지 않은 주제에 기반 지식도 대개는 없으시고요.

이제 글을 척 보면 아 이분 글이구나 하는 생각이 들 정돕니다.

여튼 답글이니 갑갑하지만 좀 쓰면요. ( 윗분들 답변과 중복되겠지만 -_- )
다른 분들께서 설명을 잘 해주셨지만,
cygwin은 Unix의 POSIX API를 Windows 플랫폼에서 돌릴수 있도록 해주는
( 또 그것을 바탕으로 Unix의 각종 Application을 돌릴수 있도록 해주는 )
포팅 레이어이자 API 라이브러리입니다.
넓게 보면 같이 패키징되어있는 어플리케이션을 포함한 것이고요.

hey의 이미지

vacancy wrote:
dummy999 님의 글은 늘상 이런식이네요.

질문 비슷하게 시작해서,
다른 분들이 성의있게 답변해주기 시작하면
거기에서 꼬투리 잡고 자기 의견을 내놓고
다른 사람들이 아니다, 이건 이런거다 라고 설명해줘도
거기에 계속 우기는 글을 다시고요. -_-
게다가 그다지 중요하지 않은 주제에 기반 지식도 대개는 없으시고요.

이제 글을 척 보면 아 이분 글이구나 하는 생각이 들 정돕니다.

여튼 답글이니 갑갑하지만 좀 쓰면요. ( 윗분들 답변과 중복되겠지만 -_- )
다른 분들께서 설명을 잘 해주셨지만,
cygwin은 Unix의 POSIX API를 Windows 플랫폼에서 돌릴수 있도록 해주는
( 또 그것을 바탕으로 Unix의 각종 Application을 돌릴수 있도록 해주는 )
포팅 레이어이자 API 라이브러리입니다.
넓게 보면 같이 패키징되어있는 어플리케이션을 포함한 것이고요.

저도 한 때는 그렇게 생각했지만, dummy999님의 글을 읽는게 생각보다 재밌습니다. 그리고 글에서 좀 잘난체 하는 것같은 기분이 들긴 하지만 답글 쓰시는 걸 보면 다른 분들의 의견을 받아들여서 자기 의견을 조금씩 고쳐나가는 모습도 보이구요. 우기는게 아니라 조금씩 고쳐나가는 기간이라고 보면 괜찮을 것 같습니다.
(dummy999님의 특수한 화법에 대한 팬들도 좀 생긴걸로 압니다. 저도 팬이에요 :D )


----------------------------
May the F/OSS be with you..


dummy999의 이미지

가장적절한표현이군요. 라이브러리라는거.. 그런데 단순한 라이브러리라는건
뭔가 실행할수있는것들이 필요하지않을까요?

만약 실행플그램까지 들어있다면 그냥 기타유틸리티류에 포함하면되겠구요.
아.. 제가 쉘을 분류할때 API를 추가한것은 실질적으로는 별로 필요는 없지만
모든 APP들이 자신들의 API(라이브러리)들을 가지고있는거처럼 쉘역시 그렇게
보심될꺼라고 생각했습니다.
그냥 플러그인형태의 옵션이라 보시면 좋을듯.

공통라이브러리도 포함될수있을지모르지만. 어쨌건간에 그근본은 APP에서 필요로
하는것들이므로 APP들이 필요없는 라이브러리는 있을가치가 없겠죠?
단순하게 여기서말하는 API는 쉘쪽 API라고 보시면될껍니다.

참고적으로 나름대로 공부를 하고있습니다. 그리고 그것은 제가 어떤사실에대한
명확화를 하기위한것이지 모르는것에대한 개념을 알고자 무작정 글을 쓰지는
않았고 또 그렇게 생각하고있습니다.

어쨌던 라이브러리라면 APP에 포함되는거이기때문에 cygwin은 APP라는것에대한
명확성은 확실한거같습니다. 그렇다면 구태여 포팅레이어라고 써야한다면 이것은 실제
기본 레이어와는 전혀 거리가 없는레이어로서 단지 레이어의 역할만 하기위해 포팅레이어라고
쓰는거같습니다.

----------------------------------------------------------

그리고 제가 이렇게 물어볼수있는것은 일반적인 오류라고 생각하시면좋겠군요
모든초보들이 얼마안되는 지식에서 목적하는바까지 얼마나 많은 참조를 해야하는가에대해
저같은 접근을 많이 할꺼라생각합니다.
새로운 지식에대해서 기존의 지식과 연관성을 가지고 접근하는 방법말입니다.
이건누구나 가질수있는 일반적인 접근방법이라생각합니다.
그리고 결과보다 접근과정이 무엇보다 중요하다고 생각합니다.
그과정을 확실히한다면 우리가 일상에서부터 시작해서 코어라는개념들까지 파고드는데
복잡한 참조과정을 거치지않는다는게 특징이라할수있습니다.

다시말해 전산수업에서 수업잘가르치는 사람을 보면 일상적인접근방법으로 수업을 가르칩니다.
그것은 상당한 효과를 줍니다.
예컨데 클래스라는 개념을 설명할때 붕어빵으로 요리를 엄청나게 잘하는 사람처럼요.
kldp나 기타오픈소스에서도 그런일반적인 접근방법이 많이 필요하다생각합니다.

어찌보면 cygwin처럼 포팅을 잘하는사람이 필요하다고생각하는바입니다.
그리고 제 팬들이 있다니.. 거기 어느회사인가요? : :lol:

------------------------------------
F/OSS bless you... ^^*

Prentice의 이미지

dummy999 wrote:
어쨌던 라이브러리라면 APP에 포함되는거이기때문에 cygwin은 APP라는것에대한
명확성은 확실한거같습니다. 그렇다면 구태여 포팅레이어라고 써야한다면 이것은 실제
기본 레이어와는 전혀 거리가 없는레이어로서 단지 레이어의 역할만 하기위해 포팅레이어라고
쓰는거같습니다.

Application은 단독으로(?) 실행이 가능하지만 라이브러리는 그렇지 않습니다. cygwin1.dll을 실행할 수 있나요? 고로 저는 시그윈은 절대로 application은 아니라는 데에 한표 던지겠습니다.

Scarecrow의 이미지

dummy999님의 글에서 핵심 키워드는 3개입니다.
커널, 쉘, APP

그러나 위의 3가지는 절대 일반적인 의미로 이해하면 안됩니다.
용어를 자의적으로 해석하고 사용하고 있는 분이 dummy999님이기 때문이죠.
그래서 dummy999님의 생각형태를 한번 추리해 보았습니다.

우선 커널하고 쉘이라는 것이 있습니다.
커널이 하드웨어를 담당하고 쉘이 소프트웨어를 담당하며
둘은 서로 통신을 합니다.

이런 것이 바로 객체가 아니겠느냐 말씀하시며 좋아라 하십니다.
또한 다른 사람들은 쉘이 커널과 직접적으로만 통신한다고 생각하지만
본인은 간접적으로도 통신할 수 있다고 생각하신답니다.

여기서 잠시 핵심은 아니나 짚어보면 직접/간접의 의미도 본래의 의미와 다릅니다.
직접/간접이 시스템콜/라이브러리를 얘기하는 것이 아니라
간접은 API를 통한 접근이며 직접에 대한 dummy999님의 설명은 없습니다.

이런 구조에서 APP는 소프트웨어이며 그런 고로 쉘 없이는 APP는 수행이 안됩니다.
쉘이 소프트웨어를 담당합니다.

Quote:
인간 -> 쉘(명령해석기->API) -> 커널

APP가 구동되면 쉘의 API와 바로 통신을 한다고 생각합니다.

인간-> APP->API->커널

그런데 DOC문서도 MS WORD가 없으면 있으나 마나하기 때문에
이런 관계에서 MS WORD가 APP가 아니고 쉘이 아닐까도 생각해 볼 수 있지만
절대 그럴 수 없다고 강조하며 쉘은 커널과 통신을 해야 한다고 쉘의 특징을 강조합니다.

Linux를 사용해 보니 CUI에서 X를 실행시키더랍니다.
생각해보니 쉘(CUI)에서 쉘(X)을 부르는 재미난(?) 모습이라고 느꼈답니다.
dummy999님의 과거의 행적에 비춰 더 깊이 추리하자면
오픈소스진영의 그런 CUI적인 생각 정말 문제가 있다고 생각하셨답니다.

그런데 얼마전 Windows에 Cygwin을 설치해 보았습니다.
근데 가만보니 Windows의 GUI쉘에서 Linux의 CUI쉘을 부르는 모습이라는 겁니다.
그 모습에 그만 혼란이 오신 듯 합니다.

다시 강조합니다.
지금 얘기되어 지고 있는 쉘은 dummy999님의 자의적 용어입니다.
즉 APP는 소프트웨어이며 그런 고로 쉘 없이는 APP는 수행이 안됩니다.

CUI쉘에 X쉘을 입힌 2중 구조, 성능저하를 가져오는 그런 구조
그것이 Linux라 생각했는데...
Windows에서 GUI쉘에 CUI쉘을 입힌 2중 구조라니...
철학적으로 생각해 볼 일이라 판단하셨나 봅니다.
그래서 Cygwin이라는 것이 대체 무엇이냐고 질문을 던져보신듯합니다.

이제 여기서 질문의 본 의도를 살펴보면
dummy999님의 처음 질문 형태는 주관식이나 내용은 객관식입니다.
커널, 쉘, APP 이렇게 3개중에 하나 골라야되는 3지선다입니다.

그런데 사람들이 위의 3개중에 하나를 골라주지 않으니 개념에 더욱 혼동이 오십니다.
POSIX를 계속 얘기하며 cygwin1.dll을 중심적으로 계속 얘기하는데
자신이 받아들이기에 cygwin1.dll같은 것은 그냥 APP의 한 부분에 불과
즉 msvcrt.dll같은 것이고 그렇다면 전체적으로 Cygwin은 APP가 되는 것일텐데...
자기가 생각하기로는 Cygwin은 커널은 절대 아닌거 같고
그래서 쉘이 아닐까 라는 생각을 지울 수 없습니다.

그래서 포팅레이어라는 것도 쉘의 일종이 아닐까라는 생각에 이르러
도표를 그려보며 끼워 맞추려 하십니다만
왠지 포팅레이어라는 것이 보면 볼수록 불필요한듯하고
dummy999님에게는 여전히 석연치 않은 구석이 많습니다.

라이브러리라는 표현에는 어느정도 혼동이 없는 듯 합니다만
여전히 APP는 쉘이 없으면 수행이 안되는 구조(쉘이 소프트웨어를 담당하는 구조)에서
즉 쉘의 API가 계속 맘에 걸리시나 봅니다.

개인적으로도 글을 읽으며 의사소통에 큰 어려움을 느꼈던바
한번 정리해 보았습니다.

vacancy의 이미지

http://cygwin.com/faq.html

Quote:
The Cygwin tools are ports of the popular GNU development tools for Microsoft Windows. They run thanks to the Cygwin library which provides the UNIX system calls and environment these programs expect.

With these tools installed, it is possible to write Win32 console or GUI applications that make use of the standard Microsoft Win32 API and/or the Cygwin API. As a result, it is possible to easily port many significant Unix programs without the need for extensive changes to the source code. This includes configuring and building most of the available GNU software (including the packages included with the Cygwin development tools themselves). Even if the development tools are of little to no use to you, you may have interest in the many standard Unix utilities provided with the package. They can be used both from the bash shell (provided) or from the standard Windows command shell.

dummy999 님께서 혼자서 생각하고 남과 토론을 해서 학습하시기보다
자료와 서적을 통해 학습하셨으면 하는 소망이 있네요.
그간 남들이 쌓아올린 지식 체계를
혼자 생각하다가 어느 순간 '유레카 !'하고 깨달을 수는 없는 일이니까요.
더더군다나 그것으로 남들과 의사소통을 하려는 것은 더 어려운 일이고요.

dummy999의 이미지

Quote:

dummy999 님께서 혼자서 생각하고 남과 토론을 해서 학습하시기보다
자료와 서적을 통해 학습하셨으면 하는 소망이 있네요.
그간 남들이 쌓아올린 지식 체계를
혼자 생각하다가 어느 순간 '유레카 !'하고 깨달을 수는 없는 일이니까요.
더더군다나 그것으로 남들과 의사소통을 하려는 것은 더 어려운 일이고요.

제가 영어를 못합니다. 그래서 영문사이트 안봅니다.
영어사이트 될수있으면 안들어갈려고 합니다. 왜인줄아십니까?
제가 거기가서 어설픈실력으로 "Object"를 "객체"라고 번역했다가 저로인해
제가 그것은 "객체"라고 한다라고말해줬던 모든사람에게 칼을 맞을수있기때문입니다.
그렇다고 "Object"는 "오브젝트"다 라고 하는게 좋을까요?
아니면 "Object"는 "물체"다 라고 하는게 좋을까요? 물론사람들이 많이 쓰기때문에 객체라고 할수있지만. 아무도 그것이 정답이다라고 말할수없습니다.
설령 "Object"라는말을 첨한사람이라할지라도 말입니다.

제 생활신조가 이렇습니다. 어설픈영어로 영어사이트 뒤적거리지않기입니다.
아무리 영어수제라할지라도 번역의 미스는 있습니다.
왜냐면 우리나라문화는 우리나라 문화이고 외국문화는 외국문화이기때문이죠.
"서울"이라는것이 그뜻이 " Fence of Castle"이라고 안부르는것은 누구도 그것이 그런뜻이라고 장담하지 못하기때문이죠. 그러나 틀린말도 아니거든요.
그대로 해석하면 그런뜻이거든요.

그냥 제가 이건 이것이 맞아라고 한다면 외국사람들은 그렇게 믿을지모릅니다.
그런데 다른한국사람이 아니다라고 한다면 진리는 없게되는겁니다.

어설픈영어로 외국사이트뒤적거리는것은 안하려고합니다. 진짜 어쩔수없다면
대충끼워맞추기식은 하겠지만. 제가 해놓은 번역은 절때로 신뢰는 안합니다.

------------------------------------
F/OSS bless you... ^^*

fender의 이미지

한가지만 말씀드리자면, 컴퓨터든 기타 전문 분야든 '용어'는 그 분야에서 통용되는 문맥에 맞게 이해해야하고 일반적인 뜻으로 이해하려고 하면 안됩니다. 그건 영어 실력과 별 상관이 없는 문제입니다.

객체지향 언어에서 'class'란 말을 쓴다고 해서, 내가 영어 사전을 뒤져 class란 단어의 정확한 의미를 찾아 아무리 혼자 들여다 본다고 해도 객체지향이란 패러다임을 이해하지 못하면 아무런 도움이 안됩니다.

마찬가지로 shell이란 것도 그 용어가 쓰이는 분야의 사람들이 널리 쓰는 의미로 이해하고 넘어가면 그만입니다. 꼭 shell이란 것의 일반적인 뜻을 따져보고 그걸 자의적으로 해석해서 여기 저기 적용해 보는 건 재미는 있을지 모르지만 별로 건설적인 일은 아닌 것 같군요.

스타크래프트를 한다면 그냥 고스트는 고스트로, 마린은 마린으로 이해하면 됩니다. 왜 고스트는 유령이란 뜻인데 이미 죽은 유령이 또 죽을 수 있는지, 왜 마린은 해병인데 땅에서만 다니는지 따지다 보면 끝도 없고 듣는 사람도 피곤하지 않을까요? :)

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

iolo의 이미지

굳이 분류하자면 "플랫폼"이라고 하지 않습니까?
토론을 하자는 쓰레드가 아니고 자기 주장의 설파(?)를 위한 쓰레드로 보이니, 저도 긴 설명은 안하겠습니다.
전 "플랫폼"이라고 우기는 걸로 하죠-.-/

----
the smile has left your eyes...

unipro의 이미지

어찌보면 이것(영어의 부족)은 변명이나 핑계일 수 있겠네요. (저는 임의적으로 이것을 가르키는 단어를 "맥주-변명을 가르킴-"와 "닭발-핑계를 가르킴-"로 하겠습니다.) 나름대로 쌓아올린 지식의 체계가 전혀 틀리지는 않겠죠. 타당성 있는 논리와 이성으로 만들어진 것일 테니까요. 다만 그것은 다른 사람과의 대화에서 여러 어려움을 수반하죠. 로마에 가면 로마의 법을 따르라고... 해당 분야를 공부하면 그 분야에 맞게끔 용어를 사용해야 할 것입니다. 그렇게 하지 않는 것에 대해 어떤 맥주를 하고, 닭발을 댈 수도 있겠죠.(보통의 한국사람은 변명을 맥주라 부르지 않고, 닭발을 핑계라 부르지 않습니다.) 한사람을 위해서 다수의 사람들이 사용하는 용어를 바꿀 수는 없을 것입니다.

저도 영어를 못합니다. 미리 그것을 해놓지 않은 것을 후회하죠. 하지만 필요하면 봅니다. 이런 작업은 저에게는 무척 어렵습니다. :? 그러나 영문이든 한글이든 수많은 선배들이 이룩한 지식체계는 배울 수 있다는 것을 행복이라고 생각하면서 그것을 달게 받습니다. 음... 예전에...퀵소트 알고리즘을 배우는 시간에 교수님이 "이것의 발견은 대단한 것"이라고 말씀하신 것이 기억납니다. 그 때 저는 그 알고리즘을 발견하기까지 걸렸던 무수한 노력들을 날로 먹은 셈이죠.

용어의 개념을 모르때는 관련된 책이나 사이트에서 찾아보고, 해당분야의 사람에게 묻는 것이 가장 효과적일 것입니다. 용어의 개념 정리와 그 분야의 이해는 상호보완적인 부분이니까 공부하면서 서로서로 도움이 되겠죠. dummy999님의 경우... 나름대로의 용여 정의와 연구를 통해서 얻는 것이 전혀 틀린 내용은 아닐 것입니다. 다만, 이것을 다른 사람에게 설명하기가 어렵겠고, 무엇보다도 수많은 사람들에 의해서 발명되고 개발된 놀라운 지식의 체계를 이해하는데 힘들 수 있죠.

내 블로그: http://unipro.tistory.com

nohmad의 이미지

iolo wrote:
굳이 분류하자면 "플랫폼"이라고 하지 않습니까?
토론을 하자는 쓰레드가 아니고 자기 주장의 설파(?)를 위한 쓰레드로 보이니, 저도 긴 설명은 안하겠습니다.
전 "플랫폼"이라고 우기는 걸로 하죠-.-/

껍데기(shell) 나왔고, 층(layer) 나왔고, 연단(platform)까지 나왔으니
저도 하나 추가하겠습니다. 저는 환경(environment)이라고 하겠습니다.
:)

이렇게 의미없이 부정확한 동의어들을 나열한다고 해서 cygwin에 대해
더 잘 아는 건 아닐텐데, 남들이 용어를 섞어가며 설명하면,
그사람의 언어틀 내에서 이해를 해야지, 자신의 언어틀로 굴절을 시켜버리니
용어상의 혼돈이 가중되어 난독증을 유발하는 것 같습니다.

warpdory의 이미지

망치는 못을 박을 때 쓰는 거고, 도끼는 산에 가서 나무 해올 때 쓰는 겁니다.

그런데, 급할 땐 망치로 나무 해올 수도 있고, 도끼 뒷부분으로 못을 박을 수도 있습니다. 하지만.. 어디까지나... 제 쓰임대로 쓰이는 건 아니죠.

그런데... dummy999 님의 글을 보면 예전의 GUI/CUI 얘기때도 그랬고 이번에도 그렇듯이... 도끼로 못을 박는 걸 보고는 '저게 망치다.', 또 망치로 나무 하는 걸 보고 '저게 도끼다.' 라고 말씀하시면서 남들에게 열심히 주장합니다.

게다가....
누가 그게 아니라, 망치는 못 박는 거고, 도끼는 나무 할 때 쓰는 거다... 라고 얘기하면서 근거 자료들(말이 좀 애매합니다만)을 제시하면 '난 그 자료들을 보지 않는다. 글을 잘못 읽을 가능성이 있기 때문이다.' 라시며 넘어갑니다.

또한가지...
전번의 GUI/CUI 얘기때를 또 끌어내보면 ...
벽에 못을 한두개 박을 때야 망치를 쓰든, 도끼의 뒷부분을 쓰든 상관없습니다. 하지만 ... 못을 수백개 밖을 때는 망치를 써야 합니다. 도끼는 아무래도 안 맞습니다. 그런데, dummy999 님께서는 도끼가 못을 받을 수 있으니 도끼가 망치보다 못 박는데 유리하다고 계속 말씀하십니다. 도끼는 나무도 할 수 있고, 못도 박을 수 있으니 망치보다 발전된 거다. 더 좋은 거다... 라고 얘기합니다.

-------------

자... 이럴 때 어떻게 할까요 ?

저라면 그냥 망치로 못 박고, 도끼로 나무나 계속 하렵니다.


---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도

즐겁게 놀아보자.

iolo의 이미지

nohmad wrote:

껍데기(shell) 나왔고, 층(layer) 나왔고, 연단(platform)까지 나왔으니
저도 하나 추가하겠습니다. 저는 환경(environment)이라고 하겠습니다.
:)

이렇게 의미없이 부정확한 동의어들을 나열한다고 해서 cygwin에 대해
더 잘 아는 건 아닐텐데, 남들이 용어를 섞어가며 설명하면,
그사람의 언어틀 내에서 이해를 해야지, 자신의 언어틀로 굴절을 시켜버리니
용어상의 혼돈이 가중되어 난독증을 유발하는 것 같습니다.


제 의도를 정확히 이해해 주시는 분이 있으니 기쁘군요...
우리모두 용어를 남발해 보자구요-.-;
머라고 할지 궁금하기도 하고..

----
the smile has left your eyes...

fender의 이미지

그럼 다양한 의견을 종합해서 제가 결론 내리겠습니다.

Cygwin은 "Win32 platform porting layer of GNU applications and libraries in bash shell environment"입니다. 빠진거 없지요? :)

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

dummy999의 이미지

CygWin은 인간도, 작업도, 기계도, 커널도 아닙니다.
그렇다면 딱하나 단순한 APP계열로 봐야한다고생각합니다.
쉘역시 APP의 계열입니다. 어차피 커널에서 통신하는거니까요.

껍데기(shell) 나왔고, 층(layer) 나왔고, 연단(platform), 환경(environment)
쉘은 APP계열의 일종의 플그램입니다.(이건 제가 스스로 파생한 지식이아니라. 앞서말했듯
어디서 본말이라 인용한겁니다.)

layer는 추상적인 개념으로서 개념을 설명할때 역할자의 위치를 말을쓸뿐 실질적인
어떤 프로그램에서 쓰는말은 아니죠(프로그래밍이 아니라. 프로그램에서말이에요)

platform이라는것도 소프트웨어적인 OS들의 단위를 명칭하는것이 아닐까요?

environment역시 layer이랑 다른게 없습니다. 추상적인 단어일뿐이죠.
플그램에서 쓰는말이아니라. 개념에서 쓰는말입니다.

분류라는것을 할수잇어야한다는것은 그것의 의미를 정확히 알고있어야하죠.
물론 저역시 그게 완벽하다라고 할수없지만. 나름대로 객관성을 가지고 분류하려고합니다.

김치를 김치라고 불러야할지 담배를 토바코이라고 불러야할지는 아주 주관적인 판단같습니다.
그말은 그만큼 자율적이라는겁니다.
그러나 자신의 그런판단이 대화의 스트림을 끊어놓거나 이질성을 느끼게 할수있다는점은
분명한 책임으로 남을껍니다.
만약 제가 지속적으로 담배를 토바코라고 불렀는데 누군가 버럭와서 하는말이
왜 담배를 토바코라고 하냐 라고 물었다면 이렇게 대답할수밖에 없을꺼같다는생각이 듭니다.
담배는 울나라에서 자란게 아니니까. 외래어로 그대로 써야하는거아니냐 라는..
제가 그런뜻으로 말하는이유를 제가 말하기전까지는 과연 누가 알까요?
차라리 첨부터 담배라고 했다면 아무도 의심을 안했을테지만. 왜 토바코라했었는지.
에대한 의심을 가지는사람은 몇이나 될까요?

원어로 말을 하게되면 단지 그런가보다 합니다. 그냥 토바코니까 토바코지 하는그런거죠.
레이어가 뭐냐라고 물어본다면 레이어가 레이어지 뭐냐 라고 반박하는사람은 국어를 다시배워야
할 심각한오류를 가진사람입니다. 그리고 그런오류는 사람이 응용할수있는방법을 떨어트립니다.
예컨데 담배 한갑을 토바코 한 갑이라고 하는게 좋은표현인가요?
아니면 이것역시 토바코 패키지라고 해버리는게 좋을까요?
원어자체는 자국어로 번역이 안된이상 지속적인 오류는 어쩔수없고 그것이 누적되면 치명적입니다.

제가 이걸 첨에 포팅레이어라고 보지않은이유도 우리가 아는 일반적인 상식에서 포팅레이어라는건
첨부터 없었습니다. 그런데 이게 개념도 아니면서 포팅레이어라고 불러야한다면
뭔가 그이유가 있지않는가라는 점때문에 자꾸 나름대로 재해석했습니다. 이렇게함으로서 그렇게밖에
글을쓸수없었다는이유를 알수있을꺼같아서였죠,(그만큼의 반론중에 어떤하나가 설득력이있다면
그것을 나름대로 생각해봐야하죠.. 제가 원어 창시자가아닌만큼 그런 나름대로의 재해석은
필요악이 아닐까합니다.)

물론 그대답을 해줄수있는사람은 포팅레이어라는말을 젤처음한사람이 알고있을껍니다.
그렇지않는다면 누군가 그의 생각을 문서로 남겨주지않는한 절때로 모릅니다.

그렇다고 영어를 안손댈수는 없습니다.
그러나 중요한것은 외래어로서 국어에 표기해서는 안된다는겁니다.
그것은 확장성이 떨어집니다.
왜 그런단어가 쓰이게 되었는지도 모르면서 단지 그것은 그것이다라는 말도안되는 논리성은
나중에 그들이 또다른 이론을 내밀때까지 아무말 할수없는거죠.. 단지 수용만할뿐 그것으로
또다른 응용을 할수없다라는겁니다.

어쩌다보니까. 글들이 많고 길어저 버렸습니다. 그러나 그만만큼 여기에 글을써온사람들이
원어에대해 무방비로 노출되었던게 아니었을까요?
원어에대한 정확한 뜻을 알고있었다면 이런 질문조차 어색했을텐데..
정말 천차만별의 색깔론은 우리가 무분별하게 받아들이는 외국어에대한 악순환의 시작이
아닐까생각합니다.

그리고 이번에 이런문제에대한 종식을 못내리면 이런문제는 얼마든지 또생길수있습니다.

오류는 감춘다고 감춰지는게 아니다. 근본을 잡지못한다면 악순환의 향연은 뇌를 조여올것이다.
라는 말이 생각납니다.
-------------------------------------------------------------------------------
Cygwin은 "Win32 platform porting layer of GNU applications and libraries in bash shell environment"입니다.

Gnu 응용플그램과 라이브러리들이 배쉬쉘 환경에 포함된 Win32 환경의 포팅레이어다.
정확한해석이되었다면 이것을 완역했을때

APP.포팅레이어=cygwin(APP의 종류중하나인 포팅레어어는 Cygwin도 있다)의 공식이
거의 99.999%는 정확합니다. 완역한거니 이렇게 생각이 안되신다면 여러번 생각해보십시요.

위에 한두분의 글들에대한 번역의 일반적인 오류를 봤을때 제가 이거다라고 말하면 분명히 몇년후에는 cygwin은 APP일수밖에없을껍니다. 적어도 울나라에서는말입니다. 제가먼저 APP다라고 못박았으니까. 알아서 못을뜯어내고 그위에 박으십시요.

나머지의 미미한확률은 이변이 생겼을때의 경우의 수니 생각을 하지않아도 좋습니다. 여러말의 가치가 없군요.
--------------------------------------------------------------------
제가 요즘 OOP의 이론을 배우고있습니다. 아주 기초적입니다.
거기서 그러더라구요 분류를 잘못하면 그모델은 재활용이 불가능한
모델일수밖에 없다라구요..

그리고 새의 분류를 잘못하면 파리도 새가되고
비행기도 새가 될수밖에 없다는 말이 떠오르네요.

분류라는것은 그환경의 특성을 이해하지못하면 절때로 절때로 불가능한거라는걸 꼭알려드리고싶습니다. 가까운학원에서 OO의 개념을 배우십시요. 집에서 혼자 삽질하는건 바람직하지않습니다. 자신의 기준대로 해석하는것은 나중에
치명적인 오류가 발생할수있습니다. 그래도 그나마 객관적인 학원가서 배우시길 권장해드립니다.

------------------------------------
F/OSS bless you... ^^*

fender의 이미지

dummy999 wrote:

원어로 말을 하게되면 단지 그런가보다 합니다. 그냥 토바코니까 토바코지 하는그런거죠.
레이어가 뭐냐라고 물어본다면 레이어가 레이어지 뭐냐 라고 반박하는사람은 국어를 다시 배워야할 심각한 오류를 가진사람입니다. 그리고 그런오류는 사람이 응용할수있는방법을 떨어트립니다. 예컨데 담배 한갑을 토바코 한 갑이라고 하는게 좋은표현인가요? 아니면 이것 역시 토바코 패키지라고 해버리는게 좋을까요?

아마 제가 쓴 글에 대한 답변인 것 같은데 제 생각에는 더미님이 '용어'와 일반 외래어를 구분 못하고 계신게 문제 아닌가 싶습니다. 담배는 일반 외래어지만 shell, layer, class 등등은 컴퓨터 용어로서 고유한 의미를 지닙니다.

그런 식으로 따지면 "인터넷 웹브라우저"가 뭔가요? "망-사이 그물 넓게 쓰는자"인가요? 인터넷을 한번도 안써본 사람에게 그렇게 설명하면 얼마나 이해할 수 있을지 모르겠습니다. 용어는 우리말로 바꾸던 안바꾸던 용어로써, 즉 해당 분야의 문맥에 맞게 이해하면 그뿐입니다. 님 혼자서 용어를 마음대로 재정의 한다면 누가 뭐라할 사람은 없겠지만, 의사소통을 불가능하게 하는 것 이외에 어떤 이익이 있는지 모르겠습니다.

그리고 사족이지만 진짜로 님의 글을 읽다보면 저나 더미님 둘중 한명은 분명 '국어를 다시 배워야할 심각한 오류를 가진(이런 번역체 표현부터 고쳐보심이... -_-) 사람'임이 분명해 보입니다. 왜냐하면 님의 글은 항상 질문을 하는 건지 주장을 하는 건지, 또 뭘 말하고자 하는지 하나도 파악할 수 없기 때문입니다. 저만 그런가요? :?:

참고로 "Win32 platform porting layer..."는 장난으로 이제까지 나왔던 cygwin의 정의에 사용된 용어를 다 조합해서 만든 겁니다. 너무 심각하게 받아들이시는 것 같군요 -_-;

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

맹고이의 이미지

매번 느끼는 것이지만
dummy999님의 글을 보면 무엇을
말하려는 건지 모르겠습니다. -_-

cjh의 이미지

음.. 읽다보니 "솔라리스는 정확히 뭐죠?"와는 물음과도 비슷한 생각이 드는군요. (솔라리스란... 이거 복잡하죠 - OS말입니다).

어쨌든... 너무 복잡하게 이해하지 맙시다. 이건 이거같고 저건 저거같으면
아무것도 이해할 수 없습니다.

그냥 저는 cygwin = Win32 플랫폼 상의 UNIX API 호환 라이브러리(cygwin1.dll) + gcc/binutils 툴체인 + 여러 유닉스 어플리케이션 패키지 세트로 이해하고 있는데 이걸로 그렇게 말들이 많은 이유를 알 수 가 없군요. 제가 너무 간단하게 여기는 건가요?

--
익스펙토 페트로눔

warpdory의 이미지

dymmy999 님의 글을 읽다보면 ... 무슨 철학책 읽는 느낌이 듭니다.
그래도 컴하고 근 20년은 살아서 어지간히 웬만한 건 알아듣는다고 생각을 하는데... 너무 어렵습니다. 딴 세상 소리.. 비슷하게 들리네요

쓰여 있기는 분명히 한글인데 ... 이해가 안됩니다.

그렇다고 제가 한자나 영어에 푹 빠져 있어서 영어나 한자가 끼지 않으면 이해 못하는 것도 아니고 ...

그냥 .. 양자역학책이 더 쉬워 보입니다. 오늘 7시부터 실험동이 정전이래니깐, 그냥 양자역학책이나 한번 더 보렵니다.


---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도

즐겁게 놀아보자.

dummy999의 이미지

그리고 말씀드리는건데 제가 주장을 굽히지않는게 아닙니다.
그만큼 여기서 수용할만큼 수용했다고 생각합니다. 그럼에도 불구하고 주장을 굽히지못하는것은
그것은 분명히 일반적인 오류라고 생각하기때문입니다. 우리가 일반적인 지식이라고 생각하는
레이어에서 그분류가 없는 포팅레이어인데 아무리예외라할지라도 프로그램이고 소프트웨어라면
분명히 커널이나 APP중하나이어야하는건 당연한건데 그런범위를 벗어나서는 대체 정체가
뭔지 확실한 근거가 없다는게 저의 생각입니다.

그렇다고 제주장이 맞아서 그런거냐? 물론 이것역시 나름대로 근거를 펼쳐보이지만
이게 꼭 맞다라고 말하기 힘듭니다. 단지 중요한것은 처음 우리나라에 오브젝트라는말이
객체였나 물체였나의 완역의 차이처럼 지금저역시 그런차이라고 말씀드리고싶습니다.

UFO에서는 물체로 쓰이고 OO에서는 객체로 쓰이고..
우리말에 물체와 객체는 똑같은말이 아닌걸로 알고있거든요.
--------------------------------------
fender님께서 혹시 자신의 글이아니었냐고 물어보셨는데 찾아보니까 님의 글은 아닌거같네용
그리고 그렇게 노골적인 물씀은 안해주셨음합니다. 저역시 특정대상을 대고 쓴글은 아닌데
그렇게 혹시 자신의 글이 아니냐고 물어본다면 저도 난감하거든요.
필요하다면 제가 인용구호를 써서 글쓰도록 하겠습니다.

그리고 fender님께서 그거 쓰신거는 진짜인줄알았습니다.
(순진하게 속아버린건가..?) -_-;;;
출처가안써있었을때 눈치깠어야했었는뎅..

그리고 저는 한국사람이지만 제 국어 표현은 사람들이 쉽게이해하지못한게 그간의 제가봐온
경험담이라고 해야할까요? 여튼 그랬습니다.

같은 한국사람들끼리 왜 한국말을 모를까요? 그런데 중요한것은 제가 글을쓰게되면
외국인들은 아마 제가 쓴 글들에대한 번역을 모두 포기해야했을껍니다.
왜냐면 그글들에는 제생각이 들어있거든요. 그건저뿐만아니라. 누구든지 자신이 뭘하던간에
자신의 생각을 글로쓰는거는 당연하다생각합니다.

제생각에는 제글을 이해할려면 저와 생각의 사이클을 똑같이 또는 비스무리하게 맞추면
그나마 저랑 생각의 공유가 가능해지지않을까합니다.

제가 번역본을 읽을때 그렇게 읽곤하거든요. 그사람의 생각을 모르고서는
그사람이 무슨생각으로 그렇게 글을썼는지 전혀모르니까요..
그런데 대부분은 번역본 않좋아라합니다.

------------------------------------
F/OSS bless you... ^^*

onion의 이미지

....웬지....
자랑도 아닌거고해서
걍 넘어가는것도 괜찮을까 했는데.....-.-;

http//onionmixer.net/~onion/booklist.html

뭐 저희회사에 있는 책의 list라..대단한것도 아닌것들이지만
더도말고 덜도말고..딱 이만큼만 책 읽으시길...
그러면 스스로 컴맹은 면했다 생각하게 되실겁니다.
(하지만 저는 만년컴맹이죠 ㅋㅋㅋ)
그러면 지금하신말에 얼마만큼 오류가 있는지
스스로 알게 되실겁니다........-.-;
(....cygwin에 대한건..님의 생각처럼 정의가 없는것이 아닙니다.
다만 그것의 존재에 대한 가치때문에
섣부르게 정의를 내리지 않을뿐이죠.....)

-----새벽녘의 흡혈양파-----

ps. 흠..참고가 될까하여 말씀드리지만...
kldp는 공공의 장소(뭐 순선옹이 갈구시면 할말은 없습니다만..-.-) 입니다
이런곳에 글을 올리시는것에서
남들이 dummy님의 생각에 맞춰라 그럼 이해할 것이다....라는것 보다는
dummy님이 일반적인 것들에 맞춰보시면 아마 다들 답답한것은
훨씬 쉬울듯합니다.
dummy님의 개성이 우선이라 생각되시면
여기서 사람들에게 의견을 묻고 대화를 하실 필요없이
dummy님의 홈페이지에서 글을쓰신다음
홀로 만족하는게 가장 좋은 방법인듯하군요.
kldp는 dummy님의 훈련 또는 트레이닝 장소가 아닙니다.
의견을 공유하고 발전하는곳이지
자신의 의견만을 피력하고 자신의 기준을 강조하는
그런 장소는 아니라고 생각합니다.

-----새벽녘의 흡혈양파-----

fender의 이미지

제가 좀 과격하게 쓴 느낌이 있군요. 그점은 사과 드립니다. 하지만 아직도 용어와 일반 외래어에 대해서는 제대로 이해하지 못하고 계신 것 같습니다.

UFO의 'Object'는 말 그대로 일상적 의미에서의 '물체'입니다. 이건 그냥 사전적 정의대로 '물건', '객체' 등등으로 이해하고 넘어가면 그만입니다.

반면에 OOP의 Object는 사전적 정의로만 이해할 수 없습니다. 일반적으로 클래스의 인스턴스를 객체라고 표현하는데 이를 이해하려면 역시 '클래스'와 '인스턴스'의 의미를 이해해야 합니다. 또 '클래스'를 이해하려면 '메소드'니 '속성'이니 하는 개념을 알아야 합니다... 이런 식으로 OOP의 'Object'는 OOP란 패러다임, 혹은 시스템의 개념들의 상호 관계로 정의되는 경계 안에서만 의미를 가집니다. 이를 자의적으로 영어사전에 나온 뜻으로 해석하려 해서는 안된다는 뜻입니다. 그래서 OOP를 이해하지 못하는 사람에게는 '오브젝트는 오브젝트다'라는 말이 나올 수 밖에 없습니다.

혹시 이걸 'Object'가 아닌 '객체'로 바꾸면 되는 것이 아닌가 하고 생각하실 수 있지만, 그것 역시 우리말로 바뀌었을 뿐, 똑같이 OOP의 경계 안에서만 의미를 갖는 용어입니다. 예를들어 이런 시스템의 경계를 무시한다면, 자바의 객체는 분명 메소드와 속성을 가질 수 있는데, 그럼 인식론의 객체도 메소드를 가질 수 있다는 뜻인가요?

따라서, shell이니 layer니 하는 개념 역시 더미님 처럼 일반적으로 접근 해서는 본질을 파악할 수 없습니다. 이 점에 대해 다시한 번 신중이 생각해보셨으면 합니다.

그럼~

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

wkpark의 이미지

dummy999 wrote:

우선 커널이라는것은 그냥단순한정의로 봤을때
사용자로부터 기계를 제어하는데 필요로하는 일련의 명령들을 담아두는곳을 의미하겠고
그런형태는 사용자쪽보다는 기계쪽에가깝다고 보는편이 좋을듯합니다.
그래서 사용자가 직접적으로 명령을 줄수는 없죠.

그위에서 쉘이라는게 인간의 명령을 번역해주죠. 다시말해 인간과 기계사이에서
커널은 기계쪽의 인터페이스를 쉘은 인간쪽의 인터페이스를 해준다고 봐야합니다.
그런데 이것들은 객체라는 단위로 볼수있습니다.

단어를 엄격하게 규정하려 하시는 듯 한데, 위의 두 문장을 보면 커널과 쉘에 대한 단어를 거의 새롭게 정의하여 사용하고 계십니다.

쉘이 인간의 명령을 번역해 주나요 ? (영화 너무 많이 보신듯) 쉘은 단지 쉘의 내부 명령인지 쉘의 외부 명령인지 구별하고, 내부 명령이면 쉘에 내장된 함수를 호출하는 것이요, 외부 명령이면 외부 명령 프로그램을 실행하는 일을 할 뿐입니다.

따라서 shell이 기계쪽에 가깝다는 말은 이상한 논리입니다. 우리가 잘 알고 있는 shell인 bash/tcsh는 일반 어플들과 다르지 않습니다.

게중에서 우리에게 가장 널리 알려진 쉘이라는 프로그램인 bash, tcsh등등은
터미날 작업으로 키보드로 명령을 전달받아 터미널에 뿌려주는 그러한 어플들을 가리키는 것입니다.

이 개념이 좀 더 확대되어 다음과 같은 정의를 하고 있습니다.

http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?query=shell

요약하면, shell은 외부 명령(프로그램)과 내장 명령을 처리하는 프로그램입니다.

온갖 참된 삶은 만남이다 --Martin Buber

unipro의 이미지

dummy999님은 OO을 열심히 하시는 것 같아요.
시간나시면 강좌란에 글을 올려주세요.
OO에 대해서 많이 배우겠습니다. ^^

내 블로그: http://unipro.tistory.com

hey의 이미지

오늘 이 쓰레드를 다시 보면서 dummy999님을 조금 이해할 수 있게 되었다는 생각이 듭니다. :D


----------------------------
May the F/OSS be with you..


saxboy의 이미지

푸하. 너무 재미있어요.

akpil님, fender님, pynoos님을 위시하여 성의있는 답변을 올려주시는 모든분들... 너무 존경합니다. :shock:

cygwin이라는 제목 하나로 이렇게 긴 스레드가 생길 수 있을 줄은 상상도 못했네요. 아 놀라워라.

zltek의 이미지

dummy999 님 혼자서 정의하시고 좋아라 하고 계셨으면 하는 바람입니다. 마침 KLDP 위키도 있고 하니 거기서 페이지 만드신 다음에 끄적이셨으면 좋겠습니다.

"no error was found with his codes"

cjh의 이미지

dummy999 wrote:
우리가 일반적인 지식이라고 생각하는
레이어에서 그분류가 없는 포팅레이어인데 아무리예외라할지라도 프로그램이고 소프트웨어라면
분명히 커널이나 APP중하나이어야하는건 당연한건데 그런범위를 벗어나서는 대체 정체가
뭔지 확실한 근거가 없다는게 저의 생각입니다.

1. 포팅 레이어는... '공식 레이어 분류 목록'이라는게 따로 있는것도 아니고... 포팅(다른 플랫폼의 프로그램을 또 다른 플랫폼에서 동작하도록 함)을 위한 레이어(계층)이라는 것은 그렇게 어려운 개념이 아닙니다. 기존에 알고 계신 커널-어플리케이션의 계층 구조 사이에 적당하게 끼워 넣으시면 됩니다.
신조어같이 들리실지 모르겠습니다만 그렇게 말한다고 해서 무슨 근거까지 필요할 것은 아닌것 같네요.

2. 프로그램이 커널이나 APP(어플리케이션이라 치겠습니다)중 하나라는 것이 전혀 당연하지 않습니다. cygwin의 핵심은 cygwin1.dll인데 이건 라이브러리입니다. 라이브러리도 프로그램의 일부지요. 단독으로 동작하지 않을 뿐입니다.

--
익스펙토 페트로눔

vacancy의 이미지

dummy님 궁금한게 있는데요.
왜 글을 처음에,

Quote:
cygwin을 종류로 구분지어야할때 이것을 정확히 어떤장르에 넣어야 좋을까요?
에뮬레이터라고 해야할지 아니면 그냥 유틸리티일련지 아니면 또다른쉘이라고 해야할지..
왜냐면 cygwin은 그만큼 모호성이 있어보이기때문입니다.
저는 이게 쉘쪽에 가깝다고생각합니다.
어떤쉘이든간에 커널과 통신을 하고 그기반에서 APP를 돌리기때문에
그런속성을 cygwin은 만족하고있다고 생각하기때문입니다.

아울러 이건 질문인데 걍 쓰는김에 같이 쓸께용.
cygwin에서 linux_logo라는 프로그램을 돌릴려고하는데 이걸쓰려면 glibc가있어야합니다.
이것이 뭐하는 라이브러리이며 또 cygwin용에서 돌릴려면 어디가서 받아야하는지
궁금합니다.

참고로 첫질문은 철학적인개념이 있을꺼같아서 여기에 넣습니다.
두번째 질문은 꼽사리입니다. 그래도 두번째 질문에도 답좀 해주세용 ^^;

.. 라고 질문인 것처럼 올리셨는지요 ?

그냥,

Quote:
cygwin은 application입니다.

이렇게 한 줄로 올리시면 더 좋았을 뻔 한 것 같습니다.

괜히 논쟁만 길어져서, -_-
이 스레드를 쭉 보면
dummy님 아니면 나머지 모든 분들,
양쪽 중 한쪽이 아주 심각한 문제가 있는 것 같네요.

dummy999의 이미지

새로운정의 : 제가 계속말했는데 일반적인형태의 오류를 포함하는 정의를 했습니다.
물론 저보다 레벨이 높은사람들에겐 상당히 오류에 모순덩어리로 볼수있습니다.
그러나 일반적인 오류를 포함하는 정의는 거기서부터 시작하면 끝까지
타고 올라갈수있다는 일종의 시작 포인트를 의미하고있다고 생각합니다.

전산에서 자신이 무엇을 어떻게 왜 배워야하는지를 아는사람은 성공한사람이라고
누군가그러던데 일반적인 오류에의한 정의는 상당히단순하면서
마치 단단한 코코넛덩어리에 뭉퉁한 칼날을 꼿는격이라고 보심좋을꺼같네요
그래서 그단어가 반쯤은 맞았다면 뭉퉁한 칼날이 코코넛덩어리에 꼿힌거고
전혀 맞지않았다면 다치지않았나를 봐봐야할꺼에영

그리고 그 코코넛덩어리를 까버리는게 오류를 배제할수있는 추가적인 기술인데
어찌되었던간에 코코넛은 누구도 까주지않았습니다.스스로 까야하는거아닌가요?
만약 코코넛걱정을하신다면 스스로 뭉퉁한칼로 까는방법을 알려주십시요.
그럼 누구나 코코넛을 그방법대로깔껍니다.

그것이 일반적인오류라는겁니다. 저뿐만아니라. 이세상에 모든사람들이 그런
위험천만한 짓을 하면서 코코넛을 까고 용어를 정의합니다.

그리고 첨부터 코코넛을 까려면 질량을 잘고려해서 중심점을 고정시키고
일정속도로 내려쳐서 떨어지는 코코넛액체를 한방울도 안흘리기위해
몇리터이상의 대접을 깔고해야한다 라고 상세하게 말씀해주시는건
어차피 특색있는 방법입니다.
그때쯤되면 다른사람은 다른방법으로 코코넛을깔수있습니다.
더 완벽한방법으로 말이죠.

그리고 정의라는것은 대중성을 얻지못하면 지금의 저처럼 완전히 저만의 정의가 됩니다.
누구도 그것이 표준이라고 인정하지않는다면 표준은 첨부터 존재하지도 앞으로도 존재하지않습니다.
일반적인 오류를 고수들도 인정하고 코어에대한접근방법을 같이 의논하지 않을꺼라면

님들이 어떤식으로 비평을해도 한귀로 흘려들을껍니다.
도와준건 아무것도 없으면서 잘못되었다고 꼬사리만 넣은다면 대체 무슨발전을하며
무슨 스텝바이스텝을 노린다고 하시는지요?

단순하게 사이트 떡하니 갈쳐주고 거기서 찾아봐라 하고 찾아보면 온통 새까만 영어들의
조합으로 눈만아프게 합니다.
문서라는건말입니다. 적어도 제가 학교에서 배울땐 정보전달의 기능을 담당한다고 들었습니다.
그런정보전달 도구가 대중성이 없는상태로 배회한다면 그것은 그냥 일개의 메모리낭비이며
종이조가리를 재멋대로 낭비하는 자연의 어머니에대한 모독입니다.
여튼 어떻게 생각하던지간에 한마디로 일축하면 상당히 소모적인 삽질밖에 안된다는겁니다.
제가 오픈소스에대해 비판하는궁극적인이유가 거기에있습니다.

사다리의 처음도 없이 몇미터위에서부터 다리 만들어주고 알아서 올라오라면
어떤 일반적인 사람들이 올라갈수있겠습니까?

마치 스스로 코코넛처럼 안으로 정보공유하려하지 외부인에게 어떤식으로 개방하려고
노력이나 한적이있었습니까? 그누구도? 고작한다고 해놓은게 초보에겐 알아듣기힘든
용어로만쓰이는 암호학같은 느낌이드는 그런 문서를..

인간의 관점에서 코코넛은 먹어라고 있는것이지 안으로 썩어라고 있는게 아닙니다.
그리고 무식하게 둔기로 먹지도못할코코넛만 치는것을 생각하면서
좀더 예리하고 더 날카로운 도구로 코코넛을 열고 먹게하는게 인간의 뇌라고생각하는데요
그렇게 계속발전하라고 있는게 인간의 관점에서 코코넛의 진리가 아닐까요?
제가 틀렸습니까?

어찌어찌하다보니까. cygwin에서 과거에 있던 일까지 들춰내기시작했는데
솔직히 그런말까지는 하고싶지않았습니다. 소모적이다라고 생각해서 였는데 또다시 소모적인 형태로 가벼렀군요..

뭐 제가 여러분들의 어머니나 아버지도 형이나 동생도 아니라서

이제 막배우는 새내기중한명으로서 여러분들께 당부드리고싶습니다.
그냥 제글을 쏘시려면 욕까지 섞어도 좋습니다.
그러나 저같은 초보자들도 보고있을껍니다. 다른건 몰겠지만 그들의 등을 긁어줄수있다면 제가 총대를 매고싶습니다. 물론 저역시 그런 지식에대해 목말라합니다. 그러니 쏘고나서 꼭 점진적인 의견제시도 부탁드립니다.
적어도 이스레드에서는 내생각은 이랬는데라는 그런점말이에요..

부탁드립니다.

------------- 글쓰면서 그사이에 올려진글들에대한 댓글입니다.(추가했음) ----------
cjh님 어려운개념이라서 제가 일부러 포팅레이어에대한 개념을 말하지않은게 아닙니다.
일반적인 레이어에서 그것은 원래 없었습니다.
그런일반적인 레이어는 아주오래전부터 만들어진거고 앞으로도 이변이 없다면 거의 변하지
않습니다. 거기서 예외사항은 없습니다. 지금까지 거의 99%가 그레이어를 준수했습니다.

그런데 어느날 cygwin이 나타나서 나는 예외다라고 한다면 왜 그렇게밖에될수없는지를
밝혀야하고 그런예외적인 사항은 또 어떤부분에서 나타날수있는지에대한
분류가 필요하다생각합니다.

제가 그거때문에 단지 일반적인시점에서 바라보려한거지 개념자체를 이해를 못해서가 아닙니다.
이정도 스레드인데 귀가 달았지만 아직까지 이게 왜 예외일수밖에없는건지 정확한 접근은
없어보입니다.

그리고 왜 그런분류가 필요한줄아십니까? 만약 또다른어떤녀석이나타나서 나역시 예외적이다
라고 말했을때 뭐라고 해야겠습니까? 또다시 지구상어떤나라에서 우리같은 소모적인 스레드논쟁만할뿐입니다.

OO에서 가장중요한것은 재사용성입니다.
여기서 확실한 분류를 해둔다면 앞으로도 예외에대한 많은 혼란은 이것하나로 종식할수있습니다.
그리고 CygWin이 라이브러리라는것도 대충 이해는했습니다.
그러나 그것을 실행시켜주는것들과 어떤연관성이 있기때문에 그것이 실행되는거라고 생각합니다.
지금제가 봐서는 bash.exe라는놈이 라이브러리 런쳐같은데 그런데 이렇게 생각하면
모순이 상당히 클수도있습니다.

그리고 vacancy님 첨부터 제가 "cygwin은 application입니다." 라고 했던가요?
분명히 그글은 중간쯤에 여러가지의견으로인해 얻어진 저만의 답입니다.
그리고 아직검증받지않는 답이기도합니다. 그리고 더중요한것은 설령 그넘이 APP라할지라도 그것의 분류가 어떻게 되는가가 중요한것이지 APP라는것은 추상적인 단어의 뜻일뿐이라 생각합니다.

제가 첨부터 cygwin이 app였다고 말하지못했던것은 그때는 그게 쉘이라고 생각했기때문입니다.
그만큼 많은부분을 수용중입니다. 그리고 위키를 크게 좋아하지도 않을뿐더러 사용법도 모릅니다.
그리고 무엇보다 중요한것은 거기에서는 "왜?"라는질문조차 내릴수없고 설령내린다해도
검증받지못한것들일뿐일껍니다. 어느날 한순간에 고치면 끝나버릴테니까요

------------------------------------
F/OSS bless you... ^^*

onion의 이미지

....object orientation은 님의 생각처럼 그렇게 간단하게 정의될 수 있는 성질의 것이 아닙니다.
님의 말씀처럼 oo가 재사용성을 가지고 있는것은 맞으나
oo의 최종적인 목표는 재사용성을 위한 구조가 아니라
유지보수를 위한 구조입니다.
유지보수를 굳이 재사용성으로 정의한다면 모를까
유지보수란것은 재사용성으로 모두 정의되지는 않습니다.
그것에 대한 얘기는 리팩토링에 나와있으니 제발 한번만 읽어주시기 바랍니다.
oo를 공부하시는 분이라면 자바에 관련된 객체지향을 공보하지 마시고
Gamma의 design pattern을 읽어주시기 바랍니다.
프로그래밍을 짜는데 있어서 많이 사용되는
pattern을 정의한 책입니다.
읽으시면 왜 OO가 단순한 재사용이 아니라
더 나은 구조를 만들기 위한 방법론인지 아시게 될겁니다.
OO도 역시 내부에서 어떠한 것을 구현하던지간에
모든것이 객체처리되는것은 아닙니다
때에 따라서는 내부에서는 structual 기법을 사용하기도 합니다.
OO적으로 판단하고 분석하는 것은 좋으나
모든것을 OO에 맞춰 판단하지는 마시기 바랍니다.

아미 아시고 있겠지만 OO에서 많이 사용되는 pattern이라는 것은
본래 건축쪽에서 사용되던 용어입니다.
그걸 software컨소시움등에서 사용하면서
OO를 대표하는 용어중의 하나가 되어버렸죠

OO의 시작은 컴터에 대한 좋은 프로그램 방향이 아니라
컴터 프로그래밍을 할때 어떻게 하면 사람이 생각하는 것과
가장 근접하게, 그렇게 함으로서 얻어지는 이익에 대하여
많은 고찰과 연구가 이루어 진 끝에 나온 것입니다.

이렇게 OO의 역사는 이렇고 현재의 목표도 저것에서 크게 바뀌지는 않습니다.
dummy999님이 생각하실때 OO가 모든것인것처럼 생각하시지만
실상은 그렇지는 않다는거죠.

design pattern에서 언급하듯이 22개의 pattern으로 모든것이 표현된다면
왜 매년 학회에서 새로운 pattern들이 발표될까요....
이것은 다양성에 대한 증거입니다.
생각하지 못한것은 어디에든 있을수 있고
그런것에 대한 새로운것은 언제든지 나올 수 있다는거죠
시간이 지나면 OO보다 더 진보된 개념이 있을수도 있는겁니다.

다시한번 말씀드리지만
(뭐 이 글이 dummy999님께 얼마나 납득이 갈지는 모르겠습니다만)
일단 무엇에 대한 정의를 내리실때는
"나는 XXX라고 생각한다. 그럼 다른분의 의견은 어떠한가"
등이라던가...(이건 그래도 많이 지키시려 한다고 봅니다)
"아 그럼 XXX가 XXX라고 한다면 내 XXX는 이렇다."
라는 과정에서 다른분의 말을 귀담아 들어주시기 바랍니다.

끝으로....dummy999님..본인이 공부하시는 입장이라고 말씀을 하셨는데...
정말로 본인이 그리 생각하신다면...
스승은 한사람만이 아니고 그사람이 얘기하는것이 진실의 전부가 아닐수도 있습니다.
어쩌면 dummy999님의 현재 상태를 고려해서 일부러 일정 수준 이상의 말은
말씀을 안하고 계실지도 모릅니다.

화학에서 이런말을 들었습니다
"화학은 하나의 공식과 수많은 예외로 이루어져있다"
아마 고등학교때 화학을 공부하신 분이라면 무슨 뜻인지 아시리라 생각합니다.

kernel, os 이러한 것들은 단순히 OO로만은 설명되지 않는것이 너무 많습니다.
또한 OO역시 OO만으로 이루어진 것은 아닙니다.
어떠한 일반적인 님께서 알고 계시는 분류 외에도
다른 방법은 충분히 많이 생겨날 수 있는겁니다.
모든것을 자신의 지식에 맞춰 형식화 하려 하지 마시고
조금만 더 크게 생각 하시기 바랍니다.

저도 공부를 많이 한 사람은 아니지만
제발 다른분들의 의견을 들어주시고
"나는 의견을 충분히 수용한다"라고 주장하시는것이 아니라
정말로 마음에서
여러분들이 제시하는 의견을 생각해보시고 책도 같이 읽어보시고...
"나는 영어 못해"라는 장벽 쌓지 마시고
대화를 해보는 것이 더 나은 방법이라 생각합니다

제가 많이 알지는 못하는 관계로
이이상의 글을 적는데는 좀 무리가 있다고 생각해서
이쯤에서 글을 마치겠습니다.

-----새벽녘의 흡혈양파-----
ps. OO라는것이 우리나라에 일부분만 알려진 것이 너무 많습니다.
제가 이 글에서 언급한 책은 모두 한글판으로 나와있고
리팩토링(1)판 같은 경우는 dummy999님이 좋아하신다 짐작되는
Java로 되어있습니다.
그리고 ....OO에 대해 약간 공부한 사람으로서 부탁 드리자면...
(뭐 결국 이게 글의 요지입니다만...)
아무데나 OO사용하지 말아주시길 바랍니다.
OO는 그런식으로 생각하고 그런식으로 사용하는 것이 아닙니다.
가르쳐준 사람마저 일부분밖에 안알려준것을
현재 배운 잣대로 모든것을 OO로 재려하지 마시길 바랍니다.

http//sslab.icu.ac.kr/oonews/

이곳에만 가셔도 많은 정보를 얻으실 수 있을거같군요.
열심히만 하신다면 좋은 결과는 나오리라 생각되지만
조금만 더 견문을 넓히신다면 더 좋은 결과를 얻을거라 생각합니다.

-----새벽녘의 흡혈양파-----

정태영의 이미지

dummy999 wrote:

도와준건 아무것도 없으면서 잘못되었다고 꼬사리만 넣은다면 대체 무슨발전을하며
무슨 스텝바이스텝을 노린다고 하시는지요?

이 쓰레드에 달린 답변들을 잘 읽어보면..
참 여러가지에 대한 자세하지는 않지만 나름대로 가볍게 설명들이 붙어 있는거 같은데요..

dummy999 wrote:

단순하게 사이트 떡하니 갈쳐주고 거기서 찾아봐라 하고 찾아보면 온통 새까만 영어들의
조합으로 눈만아프게 합니다.
문서라는건말입니다. 적어도 제가 학교에서 배울땐 정보전달의 기능을 담당한다고 들었습니다.
그런정보전달 도구가 대중성이 없는상태로 배회한다면 그것은 그냥 일개의 메모리낭비이며

적어도 전산쪽에서만큼은 한글로 된 문서가 얼마나 적은지 아직
실감하지 못하신거 같군요..

더군다나 전산쪽에서 사용되는 영어는 그렇게 복잡하지 않기 때문에..
영작까지라면 모르겠지만.. 80%이상을 이해하는건 그렇게 어렵지 않습니다..

dummy999 wrote:

제가 오픈소스에대해 비판하는궁극적인이유가 거기에있습니다.

사다리의 처음도 없이 몇미터위에서부터 다리 만들어주고 알아서 올라오라면
어떤 일반적인 사람들이 올라갈수있겠습니까?

마치 스스로 코코넛처럼 안으로 정보공유하려하지 외부인에게 어떤식으로 개방하려고
노력이나 한적이있었습니까? 그누구도? 고작한다고 해놓은게 초보에겐 알아듣기힘든
용어로만쓰이는 암호학같은 느낌이드는 그런 문서를..

걷기도 전에 뛰는건 어려운 일이죠.. 걷지도 못하는 사람한테 뛰는법을
가르쳐 주기는 더더욱요..

근데 여기서 오픈소스에 대한 비판이 왜 나오는지는 모르겠군요 ~.~

더군다나 오픈소스로 나온 라이브러리들은 대부분 API 문서화 같은건
상당히 잘 되있는 느낌을 받는걸요..

dummy999 wrote:

그리고 CygWin이 라이브러리라는것도 대충 이해는했습니다.
그러나 그것을 실행시켜주는것들과 어떤연관성이 있기때문에 그것이 실행되는거라고 생각합니다.
지금제가 봐서는 bash.exe라는놈이 라이브러리 런쳐같은데 그런데 이렇게 생각하면
모순이 상당히 클수도있습니다.

bash.exe는 라이브러리 런쳐가 아닙니다..
cygwin1.dll을 사용하여.. 윈도우에서 돌아갈 수 있도록 컴파일된
본어겐쉘일 뿐입니다..

저 위에 답변달아놨듯이.. 리눅스는 커널이지만 리눅스를 GNU/Linux라는
OS로 생각하는 것과 비슷한 착각을 하신거 같습니다..

cygwin1.dll은 하나의 라이브러리이고.. cygwin을 설치할때..
cygwin1.dll만을 설치하는게 아닌 다른 cygwin1.dll을 이용해서
윈도우에서 돌아가도록 컴파일한.. 여러가지 gnu 툴들과 함께 배포되기 때문에..

혼동이 오신듯 합니다..

dummy999님의 글에 말꼬리 잡으려는건 아닙니다..
다만.. 자신의 주관이 너무 뚜렷하신듯 합니다..

다른 분들이 올려주신 답변들을 머리를 좀 비우고 좀 더
진지한 자세로 봐주셨음 좋겠군요..

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

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

warpdory의 이미지

제 전공이 물리학이니 물리학적인 얘기를 좀 꺼내보겠습니다. 아무래도 프로그래밍을 정식으로 배운 게 1년 반 정도 밖엔 안되기 때문에(그나마도 교수랑 싸우고 때려쳤지만) OOP 는 대충 뭐다 정도만 압니다. cygwin 이 porting layer 건 application 이건 그런 게 중요하지 않은 ssh 를 돌려서 리눅스 서버에 들어가서 놀 수 있으면 저는 만족합니다.

물리학을 공부할 때... 수식만 본다고 칩시다. F=ma ... 이걸 가지고 F 는 m 과 a 의 곱이다. 라고 ... 수식만 봐서는 때려죽여도 물리학 못합니다. 수학은 잘할지 몰라도 물리학은 저게 아닙니다.
그러면 ... 저걸 어떻게 이해하느냐가 중요합니다. 대개 레포트 등에(게임이건 연애건...) 치어서 수식푸느라 그 뒤에 숨어 있는 물리는 놓치는 경우가 대다수가 됩니다.
그렇다면 뭘 보느냐 하면 질량이 무엇인지, 중력이 무엇인지, 가속도는 또 뭔지, 힘이 뭔지... 이런 걸 봐야 합니다. 개념이라고 하죠. 중력의 개념, 질량의 개념... 이런 걸 이해해야 합니다. 그런데.. 그 개념이라는 건 글로 .. '질량은 어쩌구 저쩌구 ... 해서 어쩌구... 그래서 ... 이므로 .. 해서 .. 이다.' 라고 쓰여진 걸 외운다고 이해가 되는 게 아닙니다. 말 그대로 이해해야 합니다. 아무런 의심없이 자기가 알고 있어야 한다는 겁니다. 그리고, 그 개념은 같은 낱말로 되어 있는 것은 모든 물리학자들이 같은 생각으로 가지고 있습니다. 가끔 학회에서 전혀 다른 얘기를 하는 사람들이 나오긴 합니다. 그러면 모두 재미있게 읽어 보고 '오 저런 사람도 있구나.... 특이하군.' 이라고 한번 더 생각하고 넘어갑니다. 물론... 그 새로운 개념이 많은 사람들의 공감을 얻으면 네이처나 사이언스 등에 실리고 흔히 말하는 유명인사가 됩니다. 물론, 그런 것을 위해서는 무척 많은 실험과 계산을 통한 데이터가 쌓여야 하며 그런 데이터가 다른 사람들을 설득할 수 있어야 합니다. 그런 데이터없이 주장만 해서는 아무도 인정을 안해줍니다.

제가 말하고자 하는 건 위에 다 적혀 있습니다.

너무 깊이 들어간 건 아닐런지...


---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도

즐겁게 놀아보자.

이한길의 이미지

다들 문장력도 좋으시고 분석력도 좋으신것 같군요.
저는 그렇게 문장력도 좋지 못하고 분석력도 별로입니다.
그래서 컴퓨터를 보는 시각또한 그렇게 자세하지 못합니다.
컴퓨터의 구성은 다들 생각하시듯이 하드웨어와 소프트웨어로 이루어져 있고..
그리고 이제 그 아래 소프트웨어를 가지고 이야기 중이신것 같습니다.

제가 본 소프트웨어 부분은 이렇습니다.
OS와 "바이너리코드"

물론 OS도 바이너리 코드 입니다. 하지만 제가 말하는 바이너리 코드는 특정한 OS에 종속적인 형태를 띄는 바이너리 코드입니다.
다시 말해서 그 OS의 실행 가능한 코드이지요. 그리고 OS에는 바이너리코드가 접근할 수 있도록 API를 제공하고 있으며
바이너리코드는 API를 통해 OS의 기능을 사용합니다. 결론은 쉘도 어짜피 바이너리 코드입니다.
단지 운영체제에 다른 프로그램을 실행시켜 달라고 요청해주는 프로그램입니다.
어짜피 운영체제에는 그런 다른 프로그램을 실행시키는 API가 있지요.

그럼 이 시점에서 시그윈이 뭐냐?

이건 컴파일러부터 생각해야 합니다. 시그윈을 단순히 말하면 리눅스에서 작성된 소스를 큰 수정 없이
윈도우즈에서 빌드하고 사용하기 위해 쓰는 건데... 컴파일러는 구문만 분석해서 어셈으로 바꾸는
바이너리 코드로만 된것이 아니라 라이브러리도 포함이 됩니다.

그런데 문제는 C의 문법이 표준이 있지만 ... 그리고 라이브러리도 표준이 있지만 윈도우즈에서 사용되는
컴파일러와 리눅스에서 사용되는 컴파일러의 라이브러리 구성이 표준을 포함하나 그 이상이고 그 이상인 부분은
형태가 다르게 작성되어 있다는 것입니다. 따라서 그 부분에서 말썽을 부리는데 시그윈은 gcc를 라이브러리 구조를
그대로 두고 그 라이브러리를 윈도우쪽에 맞도록 수정한 것입니다. 그래서 큰 수정 없이 컴파일하고 실행하는 것이 가능하지요.

뭐 대략 이런걸 위한것이 시그윈인데... 특별히 분류할 것은 없다고 봅니다. 단순히 개발툴이지요.
단지 윈도우즈 바이너리 코드를 생성해내면서 라이브러리 구조는 리눅스쪽을 따르는 개발툴입니다.

ps.원 글을 쓰신 분께서 perl을 서버 사이드 스크립트라 하심은 도저히 이해가 안됩니다. 그건 모드펄정도를 생각하신 거겠지요.

----
먼저 알게 된 것을 알려주는 것은 즐거운 일이다!
http://hangulee.springnote.com
http://hangulee.egloos.com

cjh의 이미지

dummy999 wrote:
단순하게 사이트 떡하니 갈쳐주고 거기서 찾아봐라 하고 찾아보면 온통 새까만 영어들의 조합으로 눈만아프게 합니다.
문서라는건말입니다. 적어도 제가 학교에서 배울땐 정보전달의 기능을 담당한다고 들었습니다. 그런정보전달 도구가 대중성이 없는상태로 배회한다면 그것은 그냥 일개의 메모리낭비이며 종이조가리를 재멋대로 낭비하는 자연의 어머니에대한 모독입니다. 여튼 어떻게 생각하던지간에 한마디로 일축하면 상당히 소모적인 삽질밖에 안된다는겁니다. 제가 오픈소스에대해 비판하는궁극적인이유가 거기에있습니다.

사다리의 처음도 없이 몇미터위에서부터 다리 만들어주고 알아서 올라오라면
어떤 일반적인 사람들이 올라갈수있겠습니까?

사이트중에서는 별 내용 없는 데도 있지만 정말 알찬 내용이 많은 곳도 있습니다. 어차피 전산이라는게 영어로 된 이상 - dummy999님도 잘 모른다는 영어를 남발하고 계십니다 - 영어에 대해 무조건 거부감을 갖고 있으면 계속 혼동 내지는 오해할 수 밖에 없습니다. 왜냐하면 원래 영어이기 때문입니다.

Quote:
cjh님 어려운개념이라서 제가 일부러 포팅레이어에대한 개념을 말하지않은게 아닙니다. 일반적인 레이어에서 그것은 원래 없었습니다.
그런일반적인 레이어는 아주오래전부터 만들어진거고 앞으로도 이변이 없다면 거의 변하지 않습니다. 거기서 예외사항은 없습니다. 지금까지 거의 99%가 그레이어를 준수했습니다.
그런데 어느날 cygwin이 나타나서 나는 예외다라고 한다면 왜 그렇게밖에될수없는지를 밝혀야하고 그런예외적인 사항은 또 어떤부분에서 나타날수있는지에대한 분류가 필요하다생각합니다.

전 이 단락을 전혀 이해할 수 없습니다. 저랑 비슷한 분도 있을 겁니다.

- 일반적인 레이어는 무엇인지
- 원래 없다는 근거는 무엇인지
- 아주 오래전이라는게 언제부터인지
- 예외사항이 없다는 것이 왜 그런지
- 거의 99%가 레이어를 준수한다는게 무슨 말씀인지
- cygwin이 왜 예외인지(예전부터 cygwin같은 시도는 많았습니다)

cygwin이 꽤 별종이라고 생각하시는 것 같은데, 다음과 같은 라이브러리나 제품을 찾아보시기 바랍니다. 그런 건 이미 여러가지가 있었습니다.

윈도우환경 POSIX/유닉스 에뮬레이션
- U/WIN (David Korn의 Win32상의 POSIX라이브러리)
- Twins 라이브러리 (윈도우 GUI 라이브러리)

유닉스에서 Win32환경 에뮬레이션
- wine (윈도우 에뮬레이터)
- Lindows (리눅스에서 윈도우 프로그램)
- SunPC (솔라리스에서 윈도우 프로그램 돌려주는 것)

그외 서로 다른 플랫폼을 이어주는 라이브러리나 호환 어플리케이션군은
상당히 많습니다. 좀 쉽게 생각하셔도 될 것 같은데...

--
익스펙토 페트로눔

minsu의 이미지

일단 dummy999님이 모두가 동의할만한 수준으로 직접 영어로 된 전문 용어를 한글로 풀어서 정의하시고 이게 확실하다! 하고 토론을 하시는게 최우선 같습니다.

안그러면 자꾸 소모성 논쟁으로 이어가지는듯하고, 누구도 , 저 또한 그뜻을 정확히 알기가 힘들거 같군요.

제가 쭉 보니까 자꾸 dummy999님께서 나름대로 설명한다고 하는데, 리플 달린 것마다 다시 그때그때 말을 바꾸시는듯합니다.

뭐던지 좀 한가지로 정해서 일관되게 밀고 나가주시길..

안그러면 보는 사람 헷갈립니다. :cry:

kslee80의 이미지

Quote:
단순하게 사이트 떡하니 갈쳐주고 거기서 찾아봐라 하고 찾아보면 온통 새까만 영어들의 조합으로 눈만아프게 합니다.
문서라는건말입니다. 적어도 제가 학교에서 배울땐 정보전달의 기능을 담당한다고 들었습니다. 그런정보전달 도구가 대중성이 없는상태로 배회한다면 그것은 그냥 일개의 메모리낭비이며 종이조가리를 재멋대로 낭비하는 자연의 어머니에대한 모독입니다. 여튼 어떻게 생각하던지간에 한마디로 일축하면 상당히 소모적인 삽질밖에 안된다는겁니다. 제가 오픈소스에대해 비판하는궁극적인이유가 거기에있습니다.

사다리의 처음도 없이 몇미터위에서부터 다리 만들어주고 알아서 올라오라면
어떤 일반적인 사람들이 올라갈수있겠습니까?

이 문단에서 할 말이 없어지는군요.
'영어' 는 정보전달용으로 사용할수 없다는 소리인가요?
'오픈소스' 라는 녀석들이 다 '영어' 라는 것을 이용해서 정보전달을 하기 때문에
'오픈소스' 자체는 '소모적인 삽질' 이다 라고 이야기 하는 겁니까?
도데체 저 문단에서 주장하고자 하는 봐가 무엇인지 전혀 알수가 없군요.

온갖 미사여구를 다 붙여가면서 전혀 상관없는 '오픈소스' 라는 녀석까지 끌어들이는
엄청난 업적을 이루셨습니다만, 좀 생각을 넓게 하실 필요가 있겠군요.

쌔까만 영어들의 조합이 눈을 아프게 한다고 그것들을 삽질이라고 이야기 하시는데
그렇다면 영어권 사람들은 전부 삽질맨들이 되는 거군요...
그런데, 실제로 영어권 사람들이 삽질맨이 될까요..아니면 영어로 무엇인가를 전달하는것을
삽질이라고 주장하시는 님이 삽질맨이 될까요.?
마치 printf() 함수도 제대로 모르는 사람이
'C 라는 언어는 프로그램 개발하는데 써먹을수 없을 정도로 형편없다'
라고 폄하하는 모습을 보는듯 싶습니다..

영어가 정보전달용으로 부적절하다고 생각되신다면,
님께서는 영어를 사용하지 않으시면 되겠습니다.
어느 누구도 영어를 정보전달용으로 사용하라고 강요한적은 없죠.
단지, 영어를 사용하지 않음으로 인한 자연적인 도태에 대해서는 책임질수 없네요.

PS) 전 세계적으로 현재 작성되어 있는 것으로 파악되는 웹 페이지의 수는
정확한 산출이 불가능 하지만, 대략 20억개 정도로 알려져 있죠.
그러나, 한글을 사용한 페이지는 고작해야 3000만개 정도로 알려져 있습니다.

PS2) 이쪽 바닥에서 필요로 하는 정보를 담은 문서(책도 포함)들에서 사용하는
영단어수준은 기껏해야 3000여 단어라고 하더군요...고등학교 수준의 영어에서
필요로 하는 단어수 정도일뿐입니다..

windpipe의 이미지

단어만 달랑 보고서 자기 나름대로 이해해버린 것을
소위 '토론'을 통해서 자기 주장을 펴고 타인에게 그 오해를 강요한다는 것을 여기서 봅니다.

dummy999님은 그것을 가지고 토론을 시도할 것이 아니라,
공부를 해야하는 겁니다. 영어라서 못하시겠다면, 아얘 토론 의제로
적지를 마셔야 하는 겁니다.

겨우 Cygwin깔고 한번 돌려보고 느낀 감상문 가지고, 뭘 토론하자는 건지요.

저도 그렇지만, 수년전 부터 Cygwin에서 뭔가 해보던 사람들이 부지기수입니다. 이 분들에게 몰라서 묻는 것이면 QnA로 가서 질문으로 올리시고, 뭔가 토론을 하시고 싶다면, 공부를 해서 제대로 개념 잡고 주제를 올리시길 바랍니다.

Cygwin하고 Object가 무슨 상관이며, 여기서 오픈소스는 왜 또 나오는지 도데체 모르겠습니다.

영어가 모국어가 아니라서 의사소통에 어려움이 있으시다구요?
올리신 글을 보니, 한국어로도 의사소통에 어려움이 크군요.

Object는 영한사전을 찾아서 거기에 나온 뜻을 기본으로 유추해서 읽으시면 안됩니다. 물리학에서 힘을 정의하는 데, 그것을 알고 싶다고 국어사전 찾아서 이해하고 문제를 풀어 나가는 것과 똑같은 것입니다. 역도 선수가 역기를 오래들고 있으면 힘이 무척 들지만, 물리적인 힘값은 0입니다. 역기가 움직이지 않는 한 말입니다.
OMG에서 설명한 정의를 보시면 명쾌하게 알 수 있습니다.
이러한 개념이 무슨 철학적인 개념인줄 착각하지 마시기 바랍니다. Computer Science에 괜히 Science가 붙는 것이 아닙니다.

이한길의 이미지

저는 시그윈을 개발툴 정도로 여깁니다. 그 이상도 이하도 아니라고 생각됩니다.
지금 현제 리눅스와 완벽한 호환을 이루고 있는 상황도 아니구요..
그냥 리눅스 환경을 흉내낸 개발툴이지요.

제가 자꾸 리눅스 환경이라 함은 사실 시그윈이 그걸 목적으로 개발되기 시작하였기 때문이지요.
시그윈 홈페이지 가보면..

Cygnus+Windows=Cygwin

이렇게 되어 있던 것으로 기억합니다.
사실 시그너스 사가 레드햇에 합병되기 전만 해도 리눅스와 비슷한 형태를 윈도우즈 위에 구현할려고
많은 노력을 했던 것 같은데 현재는 독자적인 형태로 가고 있습니다.

결국 윈도우즈 개발툴인데 라이브러리 구조를 리눅스쪽을 따르는 개발툴 입니다.
더구나 리눅스쪽을 완벽히 지원하지도 않으니 제대로 된 포팅 툴도 될 수 없구요.
사실 저도 시그윈을 분류하기 위해 다른 여타 많은 개념들이 왜 나왔는지 모르겠습니다.

----
먼저 알게 된 것을 알려주는 것은 즐거운 일이다!
http://hangulee.springnote.com
http://hangulee.egloos.com

pynoos의 이미지

잠시 cygwin과 벗어난 얘기를 해보겠습니다.
이미 cygwin에 대한 주제는 나올만큼 나왔으며, 더 이상 dummy999님이 새로이 알만한 것도, 또 다른 사람이 새로이 알려줄 것도 많지는 않아 보입니다. :)

저는 dummy999 님이 말을 바꾸신 것은 이 주제를 처음부터 애정있게 보아왔다면(?) 이른바 말바꾸기 또는 주장하는 바에 대한 변호라고 생각되지는 않습니다.

저는 dummy999님의 자세를 좋아합니다. 지식은 다른 사람과 부딪혀봐야 자신의 잘잘못을 알수 있기 때문입니다.

요즘 제 세살난 딸은 끊임없이 비교하며, 같네와 다르네, 이건 누구꺼네 등을 확인하곤 합니다. 아마 세상을 이해하는데 있어서 가장 기본적인 자세는 자기가 아는것과 다른것, 또는 두 가지 사물,개념에 대한 같고 다른 점을 비교하면서 지식을 습득하기 때문인것 같습니다.

저는 dummy999님은 그러한 비교과정을 통해 자신의 잘잘못을 확인받으며, 정확한 지식을 알려는 것이지, 뭔가 주장하여 기존의 것과 다른 개념을 보이는 것이 아니라고 봅니다.

dummy999 wrote:
이제 막배우는 새내기중한명으로서 여러분들께 당부드리고싶습니다.
그냥 제글을 쏘시려면 욕까지 섞어도 좋습니다.
그러나 저같은 초보자들도 보고있을껍니다. 다른건 몰겠지만 그들의 등을 긁어줄수있다면 제가 총대를 매고싶습니다. 물론 저역시 그런 지식에대해 목말라합니다. 그러니 쏘고나서 꼭 점진적인 의견제시도 부탁드립니다.
적어도 이스레드에서는 내생각은 이랬는데라는 그런점말이에요..

저는 그런 용기에 찬사를 보냅니다. 저 또한 용기 없을 때가 많은 데, 사실 몇 번 찾아 보거나 진득하게 매뉴얼을 읽고나면 알만한 내용이라 생각되어 자제하는 것이 습관이 되어 버렸기 때문이지요.

세상은, 적당히 아는자와 적당히 모르는자가 섞여 있는 것이 가장 아름답습니다. 너무 많이 아는 사람과 너무 모르는 사람이 있으면, 피곤해집니다.
회사에서도 너무 잘아는 사람끼리만 있으면 프로젝트가 되지 않습니다.
적당히 배우려는 자와 조금 아는 자가 비율이 맞을 때 그 시너지 효과가 가장 큽니다.

이 관점, 즉 프로젝트가 되게하려고하는 관점에서 본다면, 다시 말해 이 주제가 생산적이 되려한다면, 전 답글을 해주는 사람은 다시한번 자신의 글을 살펴보아 너무 톡쏘아 반감을 느낄만한 어조인지 살펴봐주시고 되도록 주제에서 벗어나는 글이 나오더래도 꼭 처음 주제에 관한 얘기는 자신의 의견을 조금이라도 넣어 다른 사람들로 하여금 이 주제가 생산적으로 갔으면 하는 바램이 있습니다.

논의가 생산적이 되지 않는 방향으로 가게 된다면, 이 글을 참여하고 있는 관리자로서, 좀 중재할까 합니다. 이제 cygwin 이 자신의 일에 도움이 된 경험을 얘기 해보셨으면 하는데요... 답글을 theory에서 practical case로 옮겼으면 합니다.

저도 "낙서금지와 같은 낙서"가 되지 않으려고 cygwin 얘기를 하고 마무리 하겠습니다.

제가 cygwin을 사용한 경험은 이런 것입니다.
모 회사 재직시에, 문자메시지 전송을 위한 고객사 연동용 프로그램을 작성할 때였습니다. record 하나만 DB에 생성시켜주면, field에 적힌 phone 번호로 문자메시지가 전송되고, 나중에 그 record에 전송 결과까지 전달해주는 프로그램입니다.

지원하는 DB 들을 추상화시킨 layer가 있었고, fork 방식으로 돌아가는 것이었지요. 물론 처음 개발은 linux/mysql 이었지만, 고객의 요구가 좀 다양합니까..

solaris, hpux, Windows NT, 그리고, oracle, informix, ms-sql 등을 지원하기에 이르렀습니다. 이 때, Windows NT 지원을 위해 해야할 일이 기존 소스를 VC로 porting 할것이냐였지요. 가장 빠른 답은 cygwin 이었습니다.
그리고, ODBC를 이용하는 것으로 DB 추상층을 상속하였습니다.

기존 코드 특히 fork 를 Windows thread로 바꾸기란 불가능한 것이었습니다. cygwin은 정확한 position을 가지고 있었고, 훌륭한 porting 환경이 된것입니다.

제가 생각하기에 cygwin은 처음부터 cygwin 상에서 개발을 시작하는 사람은 없다이며, 저와 같이 기존의 Unix/Linux 환경의 source를 거의 그대로 사용하고자 하는 solution으로 사용되는데 이용됩니다.

dll dependency 확인이나, call stack 등을 trace 하지 않아도, 필요에 의해 cygwin을 절실히 접했던 사람이라면, 어떤 것이 환경이며, 어떤 것이 library인지 그리고, 이 cygwin이 내 작업에 어떤 위치에서 helper가 되는지 이해되리라 생각됩니다.

제 cygwin이야기는 여기까지 입니다. :)

이한길의 이미지

pynoos wrote:
제가 생각하기에 cygwin은 처음부터 cygwin 상에서 개발을 시작하는 사람은 없다이며

처음부터 시그윈 상에서 개발을 시작하는 사람이 있습니다. 리눅스나 유닉스에 포팅해야 하는데 작업환경이 윈도우즈인경우 사용하기도 합니다. 어쩌튼 그래도 개발툴에 지나지 않다는 것이... 리눅스의 라이브러리 구조를 따르는 개발툴이라는 것이 더 적합하다고 생각됩니다.

----
먼저 알게 된 것을 알려주는 것은 즐거운 일이다!
http://hangulee.springnote.com
http://hangulee.egloos.com

unipro의 이미지

대부분 전반적으로 이해하는 것은 비슷한 것 같은데... 정리하면 UNIX(특히 LINUX)의 프로그램을 윈도우즈 환경에서 사용가능하게 하고 저렇게 이렇게 도움을 주는 ... 뭐 거시기(?) 아니겠습니까?

sigwin는 아주 재미있고 유용한 여러가지를 같이 담고 있습니다. 그래서인지 이번 쓰레드를 통해 수많은 분류와 용어들이 등장했습니다. 앞으로도 계속된다면 어떤 것들이 나올지도 궁금하군요.

우리 어머니는 여자이기도 하고, 한 사람의 아내이기도 하고, 나의 어머니이기도 하고, 우리나라의 국민이기도 하고... 그렇지만 저에게는 가장 중요한 어머니 입니다.(저랑 아버지랑 "어머니"와 "아내"라는 명칭때문에 싸운 적은 없습니다) 어떻게 부르든 아버지와 나는 누구를 가르키는지 너무 잘 알아요. 의미가 더 중요합니다.

개발을 하시는데 사용하시는 분은 개발툴요 여기시고, 포팅을 위한 유용한 중간체(?)로만 여기신다면 그렇게 이해하시고, 장난하고 싶으시면 역시 그렇게 하십시요. 정작 중요한 것은 자신에 맞게 유용하게 활용하는 것 아니겠습니까?

당신의 의견도 옳습니다. 모두 자신의 입장에서 훌륭히 이해하고 있으신 것 같습니다. 내가 아직 부족하듯, 당신도 역시 부족할 것입니다. "당신을 틀렸소." 보다는 "나는 이렇소", "당신의 생각은 재미있구려" 뭐 그런 것 아니겠습니까. 지식이 부족하다면 .. 당장은 이해하지 못하겠죠. 그러나 언젠가 더 많이 알게 되었을 때, 그때 무릅을 치면서 "아하~"하는 날이 올 것입니다. 저 역시도...

어쨌든 이런 논쟁(?)도 중요하지만, 필요할 때 자신에 맞게 sigwin을 사용하는 것이 더 중요할 듯 싶습니다.

내 블로그: http://unipro.tistory.com

vacancy의 이미지

pynoos wrote:
잠시 cygwin과 벗어난 얘기를 해보겠습니다.
이미 cygwin에 대한 주제는 나올만큼 나왔으며, 더 이상 dummy999님이 새로이 알만한 것도, 또 다른 사람이 새로이 알려줄 것도 많지는 않아 보입니다. :)

저는 dummy999 님이 말을 바꾸신 것은 이 주제를 처음부터 애정있게 보아왔다면(?) 이른바 말바꾸기 또는 주장하는 바에 대한 변호라고 생각되지는 않습니다.

저는 dummy999님의 자세를 좋아합니다. 지식은 다른 사람과 부딪혀봐야 자신의 잘잘못을 알수 있기 때문입니다.

요즘 제 세살난 딸은 끊임없이 비교하며, 같네와 다르네, 이건 누구꺼네 등을 확인하곤 합니다. 아마 세상을 이해하는데 있어서 가장 기본적인 자세는 자기가 아는것과 다른것, 또는 두 가지 사물,개념에 대한 같고 다른 점을 비교하면서 지식을 습득하기 때문인것 같습니다.

저는 dummy999님은 그러한 비교과정을 통해 자신의 잘잘못을 확인받으며, 정확한 지식을 알려는 것이지, 뭔가 주장하여 기존의 것과 다른 개념을 보이는 것이 아니라고 봅니다.

dummy999 wrote:
이제 막배우는 새내기중한명으로서 여러분들께 당부드리고싶습니다.
그냥 제글을 쏘시려면 욕까지 섞어도 좋습니다.
그러나 저같은 초보자들도 보고있을껍니다. 다른건 몰겠지만 그들의 등을 긁어줄수있다면 제가 총대를 매고싶습니다. 물론 저역시 그런 지식에대해 목말라합니다. 그러니 쏘고나서 꼭 점진적인 의견제시도 부탁드립니다.
적어도 이스레드에서는 내생각은 이랬는데라는 그런점말이에요..

저는 그런 용기에 찬사를 보냅니다. 저 또한 용기 없을 때가 많은 데, 사실 몇 번 찾아 보거나 진득하게 매뉴얼을 읽고나면 알만한 내용이라 생각되어 자제하는 것이 습관이 되어 버렸기 때문이지요.

지식은 다른 사람과 부딪혀가며 바로잡을수도 있지만요.
부딪히는 일은 기본적인 배경지식을 어느정도 가진 후에야
비로소 가능한 일이라고 생각합니다.
그래서 인터넷의 여러 사이트에는 FAQ가 있는 것이고,
FAQ를 읽어 기본적인 지식을 가진후에도 모르겠는 것들에 대해
사람들과 부딪혀보는 기회를 주기 위해 QnA란도 있는 것이겠죠.

그러나 이 스레드를 읽는 많은 분들은
dummy님이 Cygwin의 FAQ정도는 읽어봤겠구나 라거나
Cygwin을 뭔가에 활용해봤겠구나 라는 생각을 도무지 할수 없을겁니다.
제 생각에도 Cygwin깔고 bash 띄워서 맛보신 정도로밖에는
전혀 생각이 되지 않습니다.
그런 상태에서 다른 사람과의 토론이라는 건 정말 무용한 일이라고 봅니다.

그리고 dummy님께서 많은 초보자들을 대신하여
총대를 메고 있는 것처럼 적으셨는데,
뭔가 배우고 공부하려는 생각이 있는 초보자들은
이런식으로 지식을 습득하지 않습니다.
영어로 된 자료는 대중성이 없으니 못보겠다면서,
왜 외부와 자료를 공유하지 않느냐니요.

Quote:
The Cygwin tools are ports of the popular GNU development tools for Microsoft Windows. They run thanks to the Cygwin library which provides the UNIX system calls and environment these programs expect.

Cygwin의 FAQ : What is it ? 의 첫 문단입니다.
중고등학생들도 (적어도 대충은) 이해할 수 있는 문장들입니다.
이것도 나는 못읽겠다 왜 이런거 보여주냐, 하는건 정말 너무한것 아닌지요.
dummy님의 여러 글들에 달려가는 답글들을 보면
정말 kldp엔 좋은 분들이 많이 계시구나; 라는 생각이 들 정도입니다. ;;

여튼 -_-; 저도 cygwin의 사용에 대해 좀 적는게 좋을것 같아서 적겠습니다.

뭐 우선은 프로그래밍 과제를 할때 쓰는 경우가 많습니다만,
이런건 특별한 용례가 아니니 생략하고요. -_-;

일전에는 임베디드 보드에 OS를 포팅할 때 좀 사용했었습니다.
( Linux 포팅은 아니고요. )
물론 리눅스에서 하는게 더 나은 면들이 많이 있겠지만,
사실 Cygwin에서 제공하는 것 이상은 필요가 없는 상황이었어서요.
( glibc까지는 없어도 되는 상황이었고요. )
크로스컴파일러와 newlib 빌드에도 전혀 문제가 없었고 해서,
UltraEdit/Editplus가 익숙하다보니-_- Cygwin에서 작업을 하게 됐었습니다.

Cygwin + Bochs(혹은 VMware, VirtualPC)로
OS 개발하는 것도 꽤 괜찮은 개발 환경이 아닐까 싶네요.
저같이 vi 배우기 귀찮아하는 ( 익혀보려고 띄웠다 얼마 안가 닫는 -_-; )
유저들에겐 특히요.

Scarecrow의 이미지

아무래도 여기 글들의 본질(근본적인 어긋남)은 이런게 아닐까 생각해 봤습니다.
결론부터 말하면 잘난척이죠.

처음 올라온 글은 토론의 소재라기 보다는 질문에 가깝습니다.
"Cygwin이란 무엇인가?"

그런데 그런 단순한 질문의 형태가 아니고 약간 변형되어 있습니다.
자기는 Cygwin을 쉘이라고 본다. Cygwin은 참 분류하기 힘든 것같다.
철학적인 문제가 있다.

"Cygwin이란 무엇인가?"라는 단순한 질문으로 봤을때
친절하고도 훌륭한 답글들이 올라왔습니다.

상식적이라면 "답글 써 주셔서 감사합니다."
그러면서 (그래도 모르겠으면) 모르는 부분에 대해서 단순하게 다시 질문을 하던지...
아니면 답글을 바탕으로 자신이 더욱 자료를 찾아 알아가면 될 것을...
그 반응 또한 처음과 같은 방식으로 단순하지 않게 약간 변형되어 있습니다.

자신이 쉘이라고 한 것은 이런 까닭이다.
자신은 그것을 모르는 것이 아니라 단지 표현하고 있지 못했을 뿐이다.
지금 자료를 찾아보는 중이다.
자신은 그 답변을 이렇게 받아들였다.
는 식으로 자신의 이해과정 같은 것을 늘어놓습니다.

처음의 질문도 "철학"이라는 단어를 사용해 가며 단순한 질문을 이상하게 변형시켜 놓은 것이나
답글을 읽고 그냥 물러나지(?) 않고 자기의 이해과정을 언급하는 것이나
공통점은 자신은 남들과 다르며 뭔가 뛰어나다는 잘난척이 아닐까 합니다.

소리소문없이 자기 혼자 자료 찾아가며 이해하면 충분할 것
자신의 이해과정이 가지는 우수성(?)까지 보여주어 자신의 뛰어남(?)을 보이려는 의도가 아닐까 하는 생각입니다.
이런 패턴은 다른 반응들에서도 잘 나타납니다.

3자가 위의 질문과 답변을 보았을때 그 설파내용(이해과정)도 죄다 틀려 있고
그래서 "뭐 좀 이상한거 아닌가요?" 라는 글이 올리자.

그 반응이라는 것이
잘 아는 사람이 보기에는 이상할지 모르나
이런 것이야 말로 자기 학습태도의 우수성(?)이며
자신의 그런 행동이야 말로 다른 초보자를 위한 헌신(?)이라는 것입니다.

"님과는 의사소통이 힘듭니다"라는 반응에도
위와 비슷한 장황설로 반응합니다.
영어를 쓰는 미국의 문화가 어떻고 한국어를 쓰는 한국의 문화가 어떻고 따위를 거론하며
번역상의 문제 어쩌고 하시며...

글을 쭈욱 읽고 제가 느낀 점이었습니다.
dummy999님이 이상하다고 지적하는 분들도 다 이런 생각을 가지고 있지 않나 생각됩니다.
그러니 dummy999님은 자신의 행동에 대해서 한번 생각해 봐야 하지 않겠습니까?

dummy999의 이미지

cjh님의 말씀을 보니까. 가장설득력이있는거같네요.
어느정도 예시가 되니까. 공감이 갑니다.

인용
cygwin이 꽤 별종이라고 생각하시는 것 같은데, 다음과 같은 라이브러리나 제품을 찾아보시기 바랍니다. 그런 건 이미 여러가지가 있었습니다.

윈도우환경 POSIX/유닉스 에뮬레이션
- U/WIN (David Korn의 Win32상의 POSIX라이브러리)
- Twins 라이브러리 (윈도우 GUI 라이브러리)

유닉스에서 Win32환경 에뮬레이션
- wine (윈도우 에뮬레이터)
- Lindows (리눅스에서 윈도우 프로그램)
- SunPC (솔라리스에서 윈도우 프로그램 돌려주는 것)

그외 서로 다른 플랫폼을 이어주는 라이브러리나 호환 어플리케이션군은
상당히 많습니다. 좀 쉽게 생각하셔도 될 것 같은데
/인용

이렇구요

kslee80님께서 그본문만 짤라서 지적해주신부분은. 그렇게만보면. 그런문서자체가
아무짝에 쓸모없어보인다라는 식으로 보이는군요..(제가썼지만말입니다.)
그러나 문서자체가 소모적이아니라. 문서의 내용들을 의미하는겁니다.
문서라는 도구가 원래딱딱할수밖에없는데 그런성격을 좀더 중화시켜야하는게 아닐까하고
말할려고했던겁니다.
예컨데 Beej의 네톡문서는 참 잼있게 구성되어있더라구요.
솔직히 제글중 kslee80님께서 그렇게 잘라버리니까. 의도와는 전혀 다른 내용이되버린거에대해
충격적이었습니다. 물론 제가 글구성능력이 부족해서리 님처럼 그렇게 볼수있을
사람들을 고려하지못했던것에대해 정말죄성스럽구요.

여튼 문서자체가 잘못된게아니라. 딱딱한문서는 피해보자라는뜻으로 하는말이니
오해는 없으시길

글쓰다보면 글들이 특정한사람들에는 표적의 대상일수밖에없습니다.
제가 그걸알면서도 그런상황으로 많이 넘어가버리네용.
제글에대해서 지금존재하는 뭔가에대한 단점을 지적하는것들은 있을지언정 그것의
존재에대한 필요성을 지적한건아닙니다.
단점은 보완하면되지만 필요성의 지적까지는 실력이 안됩니다.

그리고 몇분이 말바꾸기라는말을 하시는데 주제에대한 변경을의미하는건지
아니면 그주제에대한 저의 생각이 바뀌는것을 의미하는건지 몰겠습니다.
그러나 전자의경우 단지예를 들어서 바꿔줄수는 있어도 절때적으로 주제에대한
포커스는 저로인한 변경은 되지않을껍니다.
후자의경우는 그만큼 의견을 수용한다는것을 의미합니다.
제가 꽉막힌사람이라면 첨부터 게시판에 글을 써야할가치가 없는거라 생각됩니다.
소모적일뿐이니까요.

그리고 pynoos님의 말씀처럼 소모적이었다면 제가 스레드잠굼에대한 요청을 드렸을껍니다.
물론 그때도 많은분들에게 총알받이가되겠죠.
어쨌든 그런점에서 관리자님께서는 저를 신뢰해주셨음하는 바램도듭니다.

그리고 이쯤해서 제가 생각하는 개념은 이렇습니다.

APP는 모든 응용프로그램을의미하고 응용프로그램은 커널위에서 돈다.
커널위에서도는것은 쉘도 커널위에서 돌게되니 쉘도 APP의 부류가된다.

APP는 실행을 직접할수있는실행기와 실행을 직접할수없는 라이브러리로 구분된다.
어차피 둘다 APP의 속성을 가진것들이고 이것들은 단지 스스로 실행이가능한가
아니면 의존성을 가지는건가의 구분일뿐이지 실질적으로는 APP의속성인 스스로
기능성을 가지는 객체로 인식해야한다.
(실질적으로 라이브러리도 컴파일된형태를 가질수있고 실행기도 컴파일된 형태를
가질수있다.)

결론은 APP는 라이브러리와 실행기로 구분할수있고(OO.특수화개념) 실행기와 라이브러리의
공통점으로 APP라는 상위개념을 만들수있다.(OO.일반화개념)
다시말해 이들은 상성관계를 가지게되므로 서로 존재가 성립한다라고 생각된다.

이를 cygwin에 적용하였을때
cygwin이 라이브러리라고했을때 윈도우즈라는 추상적인 객체는 실행기이고 추상객체가
라이브러리를(cygwin) 실행상태로 만들어주고있다. 그래서 그기반위에서
도는 모든 포직스를 지향하는 플그램들은 실행이가능하다.
라는겁니다.

vacancy님 제가말하는 영어어의 회피는 저같은 사람들때문입니다.
누구나 자신의 생각을 나타내고싶어하는데 그것이 약간모호한단어로
이렇게 생각하면 이것이 될수있고 저렇게 생각하면저렇게 될수있는 그런거때문에
그런겁니다. 실질적으로 저도 제가 좀모호한표현을 자주쓰는표현입니다.
한마디로 이건이거다라고 쉽사리 단정짓기힘든것이 영어라는겁니다.

그리고 제실력은 중학교수준도 안되는거같다는생각이듭니다.
영어는 학교다니면서리 썩 좋은점수는 못받았거든요.

어떤것이든지 인위적인것들(인간이 접근할수있는 모든것들 다시말하자면 인간의 때가 묻은것들)은
인간의 생각이 담겨져잇습니다.
자연적인 돌을보고 이게 무슨생각으로 여기에 있으며 무슨생각으로 이런모양인가에대한
질문을 할수없습니다. 그러나 인간이 만든것은 그런것을 공유할수있습니다.
그런인간의 생각을 다른말로는 철학이라고도 하더라구요.
단지 사용법이나 개념따위가 전산에서 중요한 메리트(가치)라고 생각하지않습니다.
설계를 해도 이사람이 뭘원하는가에대한게 중요하다고 들었습니다.
그래서 컨셉이니 디자인이니 하는 외래어들은 전부 인간의 생각이라는단어와 크게 다른게 없습니다.
철학은 인간이 존재하는한 무한상상의 형태를 띄고 그가치는 천차만별일껍니다.

인간이 철학적으로 살고 왜라는의문을 가지고 또 왜라는 의문의 답을 내릴수있는건
그만큼의 가치관(철학)을 가지고있기때문이라생각합니다.

돈을 버는사람도 돈을 쓰려는사람도 모두다 그런철학을 가지고 경영하고 생활하는데
단지 전산이라는 이유만으로 단지 컴퓨터오퍼레이터라는이유만으로 철학이 철저히 무시되고
이런개념이 철저하게 짓밟히는 상황이라면 무엇때문에 왜 전산을 해야하는지
아무도 답을 내리지못할껍니다.

제가 좀 이론을 좋아라합니다. 그런데 이런이론이 없었다면 과학이라는것은 첨부터 존재할수있었을까요?
이론이 없이는 발전조차 없다고 생각합니다.
따분한 탁상공론이라는 소리를 와우리눅스에서도 들어왔습니다.
그러나 분명한것은 그것은 성과있는것들이었다고 생각합니다. 누구나 열정이있다면
자신의 가치관을 가지고 일을 하고 그것은 타인의 믿음이나 소신을 의미합니다.

예전에 와우에서 제가 전산에서 젤필요한건 정(情)이다 라는 말을 했을때 많은사람들이
그것에대해 상당히 부정적이었습니다.
물론 저역시 그런말을 조리있게 할수없는상태였고 지금역시 그렇게 생각하지만
그때나 지금이나 최선을 다해 기술하고있습니다. 전산에서 가장중요한것은
결과가 중요하다고생각하지않습니다. 과정이중요하다생각하고 그과정은 정이없이는
절때적으로 진척이 없다고 생각했었습니다.

컴퓨터 첨만지고 지금까지 코딩스킬이나 전산개념에대해 소극적이었지만. 나름대로 가장
중요했다라고 생각하는것을 배웠습니다. 그것은 전산이라는것에도 정이 있을수있다라는겁니다.

아. 말하다 좀 샜군요. 여튼 중요한것은 제가 처음 의도한것은 cygwin의 분류였지만
조금씩 길어질수록 분류쪽으로 포커스가 실어졌고 그와중에 분류의 필요성을 제가 지적했습니다.
그리고 분류의 필요성을 말하면서 가장원론적인 전산에대한 필요성을 적어갔다고 생각합니다.

물론 저는 이것들이 단계적으로 이뤄질수있는 접근이라고 생각합니다. 하나하나의 스레드들이
서로의 의존성을 가지고 cygWin의 분류에있어서 가장필요한것들이 무엇인가라는것들을
스레드의 후반부쪽에 기술되어지고있다고 생각합니다.
만약 몇년뒤에 이글을 첨접하게될사람들은 이렇겠죠.
Cygwin의 분류를 무심코읽었는데 읽다보면 나올만한 왜 분류를 했었나라는것이나
왜 그게 필요했었는가? 왜 그렇게 논쟁을 해야했었나등등.. 스스로 그런 질문을 해댈껍니다.

무엇보다도 그런질문에 가장 근접한 답이고 이스레드는 가장 인간지향적인 문서가 되지않을까
생각하면서 낼까지인레포트 지금부터 해야겠습니다. -_-;;;

------------------------------------
F/OSS bless you... ^^*

onion의 이미지

숙제는 소중한것...즐거운 숙제되셈..-.-;

-----새벽녘의 흡혈양파-----

hey의 이미지

dummy999 wrote:
그리고 이쯤해서 제가 생각하는 개념은 이렇습니다.

APP는 모든 응용프로그램을의미하고 응용프로그램은 커널위에서 돈다.
커널위에서도는것은 쉘도 커널위에서 돌게되니 쉘도 APP의 부류가된다.

APP는 실행을 직접할수있는실행기와 실행을 직접할수없는 라이브러리로 구분된다.
어차피 둘다 APP의 속성을 가진것들이고 이것들은 단지 스스로 실행이가능한가
아니면 의존성을 가지는건가의 구분일뿐이지 실질적으로는 APP의속성인 스스로
기능성을 가지는 객체로 인식해야한다.
(실질적으로 라이브러리도 컴파일된형태를 가질수있고 실행기도 컴파일된 형태를
가질수있다.)


흔히 어플리케이션이라고 하면 특수한 작업을 위해 만들어진 실행 가능한 컴퓨터 파일을 말합니다. 보통 사람이 읽을 수 있는 텍스트 파일은 어플리케이션이라고 하지 않지요. 소스 코드도 마찬가지입니다. 라이브러리도 APP로 분류하지 않습니다. 컴파일 된 형태를 구분의 기준으로 삼으셨는데, 컴파일 된 형태의 파일을 무언가로 부르고 싶다면 바이너리라고 부를 수도 있을 겁니다.
위에서 이해하고 계신 부분은 지금까지 해오셨듯이 조금 수정하시면 되겠습니다.
말씀하셨다시피 쉘도 실행 가능한 프로그램이므로, 그대로 어플리케이션으로 분류하세요. 잘 하셨습니다.

dummy999 wrote:
결론은 APP는 라이브러리와 실행기로 구분할수있고(OO.특수화개념) 실행기와 라이브러리의
공통점으로 APP라는 상위개념을 만들수있다.(OO.일반화개념)
다시말해 이들은 상성관계를 가지게되므로 서로 존재가 성립한다라고 생각된다.

이를 cygwin에 적용하였을때
cygwin이 라이브러리라고했을때 윈도우즈라는 추상적인 객체는 실행기이고 추상객체가
라이브러리를(cygwin) 실행상태로 만들어주고있다. 그래서 그기반위에서
도는 모든 포직스를 지향하는 플그램들은 실행이가능하다.
라는겁니다.


라이브러리와 실행기를 더이상 APP로 구분할 수 없습니다.

cygwin의 경우 컴파일된 바이너리 파일을 실행해주는 층이 아니며, 그렇다고 하더라도 실행 파일이 라이브러리를 실행상태로 만들어주는 일은 없습니다.

여러 다른 분들이 답변 해주셨다시피 cygwin은 posix를 따르는 프로그램을 소스 코드 수준에서 호환되게 해주는 라이브러리입니다.


----------------------------
May the F/OSS be with you..


kebie의 이미지

cygwin1.dll 이 있는 경우
bash.exe : 개똥아 노올자~
|
cygwin1.dll (개똥이가 똥개를 리턴하도록 포장되어 있습니다.)
|
윈도우즈 : 똥개 주소는 XXX 에요. (윈도우한테는 개똥이가 아니라 똥개라고 들립니다.)

cygwin1.dll 이 없는 경우
bash.exe : 개똥아 노올자~
윈도우즈 : 여기 개똥이 안사는데요. -_-;

리눅스에서는 개똥이라고 부르는데 윈도우에서는 똥개 라고 한다고 하면, 리눅스에서 짠소스는 개똥이를 부르는데 윈도우에는 개똥이가 없습니다. cygwin1.dll 안에는 개똥이가 똥개를 호출하도록 포장이 되어 있어서 cygwin 에서 컴파일 된 실행파일은 cygwin1.dll 파일이 있어야만 실행이 되는 것 같아요.

위글들을 읽고 있으니, 쉘은 단지 마우스나 키보드 같은 입력장치로 사용자가 입력한 명령어(또는, 이벤트)를 해석하고 실행해주는 프로그램이고, 포팅레이어는 Bash.exe (Cygiwn 용bash 쉘) 이 실행할때 참고하는 라이브러리인 것 같이 요약이 되네요. 저는 위 글들을 재대로 이해하며 읽고 있는 걸까요... (아직도 너무 많아서 전부 읽지는 못했습니다. 읽을 수록 기반지식이 흔들리네요... )

ps.
저도 용어를 잘 모릅니다. 그래서 이런식으로 억지로 끼워맞추어 이해를 하고 있었습니다. bash.exe 나 explorer.exe가 실행파일로 존재하는 것을 보고 쉘도 그냥 프로그램이구나 하고 생각을 하고만 있었죠. (--;) 용어를 잘 몰라서 억지로 제가 이해할 수 있게 해석하려고 애를 쓰는데... 이런 것에 대해 한계를 느끼고 있습니다. 이렇게 이해해서 어느정도까지는 쉽게쉽게 진도를 나갈 수가 있었는데, 어느 단계 이상으로 넘어가면서 처음에 이해했던 것들이 맞아떨어지질 않더군요... 부실공사죠... 처음부터 재대로된 개념를 익혔다면, 재대로 이해했다면 어려움 없이 넘어갈 부분에서 너무 혼란스러웠습니다.

Scarecrow의 이미지

Quote:
설계를 해도 이사람이 뭘원하는가에대한게 중요하다고 들었습니다.
그래서 컨셉이니 디자인이니 하는 외래어들은 전부 인간의 생각이라는단어와 크게 다른게 없습니다.
철학은 인간이 존재하는한 무한상상의 형태를 띄고 그가치는 천차만별일껍니다.

인간이 철학적으로 살고 왜라는의문을 가지고 또 왜라는 의문의 답을 내릴수있는건
그만큼의 가치관(철학)을 가지고있기때문이라생각합니다.


이쯤 되면 님이 좋아하는 왜의 근거를 보여드리면 되겠지요? 쩝.
Quote:
술어 術語 (technical term)

개요
학문이나 기술의 각 분야에서 전문가들이 쓰는 특수한 용어.

내용
전문어·테크니컬 텀이라고도 한다. 학문상의 정의나 개념 또는 기술분야에서 사용하는 기계·장치·공구 등의 명칭은 정확하고도 엄밀하게 표현해야 하므로, 일반 사회에서는 쓰이지 않는 특수한 용어가 발달하게 된다. 예를 들면 수학에서의 선분(線分), 전기분야에서의 단락(短絡) 등이 그것이다.

한국어에 있어서 술어는 외국어나 번역어가 많은 점이 특징이다. 의학에는 독일어, 음악에는 이탈리아어에 의한 술어가 많다.

유럽은 각 분야의 술어에 그리스·라틴어의 영향을 많이 받았다. 예를 들어 미국에서 생긴 사이버네틱스(cybernetics)는 그리스어인 키베르네테스(kybernetes) 즉, 조타(操舵)에서 온 말이다.

근년에 이르러 각 분야별로 전문화·세분화가 이루어지면서 술어의 난립이 눈에 띄며 학문의 교류나 기술보급에 장애가 되어 술어의 통일·수정·정리가 각 분야에서 진행되고 있다.


술어의 사용은 정확하고도 엄밀해야 합니다.
대충 보니깐 비슷하다고
님이 하는 말투로 하면 "크게 다르지 않다"고
그렇게 자의적으로 쓰면 안됩니다.
컴퓨터 분야의 술어는 영어가 많습니다.

OO를 계속 인용하려 드시니 그것으로 예를 들어들이면
A라는 클래스에서 B도 상속되고 C도 상속되었습니다.
그래서 B는 A보다 더 구체적이면서 A의 특징도 가지고 있고
C도 A보다 더 구체적이면서 A의 특징도 가지고 있죠.
그리고 B와 C는 둘다 A에서 상속되었으므로 크게 다르지 않습니다.
(B와 C에 첨가된 코드만큼 약간 다릅니다.)
이제 님은 크게 다르지 않다고 B랑 C를 동일하게 취급하겠습니까?
왜 B랑 C를 따로따로 부르냐 같이 부르면 안될까? 라는 문제의식을 가지 시렵니까?

혹시 지금 컴퓨터 분야에서 사용하는 기존의 술어를 재정립해보자고 이러시는 겝니까?
영어보다는 우리말이 더욱 좋아서 그렇게 고치고 싶은 것이라면
기존 술어들에 대한 이해도부터 높히는 것이 순서입니다.
잘 알지도 못하는 것을 어떻게 정확하고도 엄밀하게 표현하시겠습니까?

아니면 Cygwin의 등장으로 컴퓨터 분야가 가지고 있던 기존의 패러다임에 변화가 요구되어
그러니깐 Cygwin의 등장으로 기존의 커널, 쉘, APP 체계에 혼란이 초래되어 지금 이러시는 겝니까?
아니잖아요.
단지 님이 Cygwin을 이해하지 못하고 있을뿐이고,
단지 님이 커널, 쉘, APP를 이해못할뿐이죠.

errai의 이미지

처음에는 간단한 질문 답변 수준에서 끝날 거라 봤던 글이 이렇게 길어져
있을것이라곤 생각하지도 못했습니다.
쓰레드를 끝까지 읽어보니, 이건 토론이 아니라 어떤 문제를 잘못 이해하고
있는 한 사람을 위해서, kldp의 여러 사람들이 제대로 이해시켜 주고자
열심히 노력하고 있는 모습이군요.
많은 분들의 수고에 답변 감사합니다라는 글은 한번도 볼 수 없고, 단지
뭐 그정도면 그 개념도 이해할 수 있겠다는 수준으로 우쭐대며, 마치
중요한 토론을 하여 큰 업적을 이룬것 같은 태도는 제가 무지해서 그런건지
이해할 수가 없습니다.

철학을 이야기 하셨는데, 컴퓨터 역시 철학과 밀접한 관계가 있습니다만,
dummy999님께서 지금 이야기한 문제는 철학이 아닙니다. 마치
코끼리의 다리만 만져보고, 코끼리는 두꺼운 통나무와 같은 분류다.
라고 주장하는 것과 같습니다. 그것도 철학이라면 할말 없습니다.

dummy999의 이미지

새삼 이쓰레드로 이걸 들척이는건 문제가좀있을거같다는생각이드는데
kldp위키에서 cygwin쳐보니까. 이게 확들어옵니다.

2003년9월13일 18:02 이때 글을썼고
지금은 오후 7:54 2004-10-20 이렇게되니까...
거의 1년만에 쓰는글같군요.. ㅎㅎㅎ
먼지쌓인 책에 먼지를 털고 글을쓴느낌입니다.

지금까지 저는 거의 cygwin에대한 관심과 광적인 삽질을 해대고싶었지만.(-_-;;;)
솔직히 조금밖에 못해봤습니다. (_ _) 죄송..

그런데 지금생각해보는 cygwin은 요몇일전에 cygwin에대한 글을 올렸을때처럼..
마치 스타크래프트\저그\건물\인페스티드커맨드센터 와 비슷하다는 느낌이들었습니다.
(\표기는.. 그냥 닷(.)대신 제가 요즘 써보고있는 표현인데.. 저는 어느정도만족하고있습니다. ;) )
어느순간 setup.exe = 퀸 이 날아와 비틀대는 NT에 확 쏴버리면(인스톨하면)
어느순간 가장강력한 인페스티드커맨드센터(cygwin이 인스톨된 NT)가 되버리는느낌입니다.

솔직히 저그라고해서 사람들이 싫어할지모르지만 저역시 저그는 싫어합니다.
그런데 마땅한 표현이.. -_-;;;

거기에 감염된테란은.. 거의 시즈탱크 같은 화력을 내더군요.. 우하하하하..

음.. 그리고 포팅레이어라는 그런거보다 버전업이 될수록
윈도우의 플러그인(에드인과 플러그인을 구분못하고있음 -_-)프로그램에 가까울정도로 윈도우와가깝더군요
그러면서 깔려버리면 유닉스에 가까워버릴정도로.. 친유닉스계열이 되버리는.. -0-

여튼 지금제생각엔 cygwin은 에뮬레이터라고 생각합니다.
어떤문서엔가도 그게 에뮬레이터라고 나오더라구요..
솔직히 에뮬레이터에 비중이 큽니다.

약간 포팅프로그램개념도있고
에뮬기능의 미들웨어격도되고.. 그러나 이것저것 전부 생략하고
에뮬레이터라고 단정지어버리는편이 좋겠더군요..

cygwin은 포팅이가능한 정말 강력한 에뮬레이터입니다.(맞나 -_-ㅋ)
1년후 생각입니다.

------------------------------------
F/OSS bless you... ^^*

bugiii의 이미지

에뮬레이터라고 얘기 한다면, 소스 레벨 에뮬레이터라고 하는 것이 좀 더 낫다고 생각합니다.

kida의 이미지

안녕하세요 유령 키다군 입니다..^^;;

dummy999 wrote:
새삼 이쓰레드로 이걸 들척이는건 문제가좀있을거같다는생각이드는데
kldp위키에서 cygwin쳐보니까. 이게 확들어옵니다.

2003년9월13일 18:02 이때 글을썼고
지금은 오후 7:54 2004-10-20 이렇게되니까...
거의 1년만에 쓰는글같군요.. ㅎㅎㅎ
먼지쌓인 책에 먼지를 털고 글을쓴느낌입니다.

지금까지 저는 거의 cygwin에대한 관심과 광적인 삽질을 해대고싶었지만.(-_-;;;)
솔직히 조금밖에 못해봤습니다. (_ _) 죄송..

그런데 지금생각해보는 cygwin은 요몇일전에 cygwin에대한 글을 올렸을때처럼..
마치 스타크래프트\저그\건물\인페스티드커맨드센터 와 비슷하다는 느낌이들었습니다.
(\표기는.. 그냥 닷(.)대신 제가 요즘 써보고있는 표현인데.. 저는 어느정도만족하고있습니다. ;) )
어느순간 setup.exe = 퀸 이 날아와 비틀대는 NT에 확 쏴버리면(인스톨하면)
어느순간 가장강력한 인페스티드커맨드센터(cygwin이 인스톨된 NT)가 되버리는느낌입니다.

솔직히 저그라고해서 사람들이 싫어할지모르지만 저역시 저그는 싫어합니다.
그런데 마땅한 표현이.. -_-;;;

거기에 감염된테란은.. 거의 시즈탱크 같은 화력을 내더군요.. 우하하하하..

음.. 그리고 포팅레이어라는 그런거보다 버전업이 될수록
윈도우의 플러그인(에드인과 플러그인을 구분못하고있음 -_-)프로그램에 가까울정도로 윈도우와가깝더군요
그러면서 깔려버리면 유닉스에 가까워버릴정도로.. 친유닉스계열이 되버리는.. -0-

여튼 지금제생각엔 cygwin은 에뮬레이터라고 생각합니다.
어떤문서엔가도 그게 에뮬레이터라고 나오더라구요..
솔직히 에뮬레이터에 비중이 큽니다.

약간 포팅프로그램개념도있고
에뮬기능의 미들웨어격도되고.. 그러나 이것저것 전부 생략하고
에뮬레이터라고 단정지어버리는편이 좋겠더군요..

cygwin은 포팅이가능한 정말 강력한 에뮬레이터입니다.(맞나 -_-ㅋ)
1년후 생각입니다.

쓰레드와는 관계없는 이야기입니다만...
제발, 글을 써주실 때 생각을 하고 써 주시기 바랍니다. -_-;;;
쓴다고 해서 글이 아닙니다.

어떻게 생각하시고 글을 쓰시길래, 각각의 문장마다 하나도 연결이 안되는 글을 작성하실 수 있습니까..-_-;;
정말 읽기 난감한 글자들의 나열이군요..
(글이라고 차마 못불러 드리겠습니다.)

토론에서의 좋은 글이란건 어려운 용어의 남발로 이루어지는 글이 아니라..
남을 이해 시킬수 있는 글입니다..
그런데,
기승전결도 하나도 없고.. 단지 용어들이 나열일 뿐인 이런 글을 쓰시면서 어떻게 남을 이해시해시키려 한단 말입니까..
정말 답답합니다.

감히 부탁하겠습니다..
제발 좀, 글을 쓰실땐 생각 좀 하시고 글을 쓰신다음 제출버튼을 누르시기전에
자신의 글을 한번 읽어보시기 바랍니다....-_-

ps) 만약 제 말이 틀렸다고 생각되시면 본인의 글을 인용하셔서,
어떤식으로 각각의 문장들이 인과관계를 가지고 기승전결의 구도로, 잘짜여진 논리를 전개하고 있는지 한번 설명해 주시기 바랍니다..
다른사람이 이해할 수 있게요..-_-;;;

안경 미소녀가 좋아~!

WaterDragon의 이미지

KLDP에 방문할 때마다 올라오는 글만 읽으면서 여러가지 좋은 정보를 많이 얻어가고 있습니다만 오늘은 이 주제를 읽어나가다보니 한 마디 안 쓸 수가 없군요.

주제를 올린 의도는 좋은 방향이었다고 생각하겠습니다.
이 정도의 진행에도 불구하고 dummy999님의 과정과 방법이 잘못됐다는 생각이 안 드시나요?
이런 식의 태도는 정말 아니다라고 말씀드리고 싶습니다.
인정하실 건 인정하셔야죠.
본인 스스로도 인정하는 특이한 화법으로 단점을 지적(영문문서 기피)하면 어줍잖은 핑계로 얼버무리면서 뭘 배워나가겠단 말입니까.

같은 궁금증을 가졌을 초보를 위해 희생하겠다는 의지를 보이셨지만, 초보의 입장에서 봐도 방법이 틀렸습니다.
본인의 욕구를 이런 식으로 해소하고 있다는 생각밖에 들지 않습니다.

좋은 의도를 갖고 질문 또는 토론주제를 올리셨다면 그땐 그에 걸맞는 태도와 자세를 갖추셔야 할 필요가 있겠습니다.

물론 공부하시면서 필요할 때 도움을 청할 순 있겠습니다.
그렇지만 지금 답글 달고 계시는 분들이 언제까지 dummy999님께 도움을 주는 차원을 넘어서 학습과정에 함께 참여해야하는 겁니까?

과제하러 가셨을테니 이 글을 나중에라도 보실 지는 모르겠군요. 초보를 위해 총대를 매겠다는 의지를 보이시니 다음부터는 보다 나은 모습을 기대해보겠습니다.

Prentice의 이미지

1년전에는 잠금요청 제도가 없었나보죠..

잠금에 한표 던집니다.

dummy999의 이미지

움.. 토론하다보면 샛길로 샐수도있는뎅.. 그걸.. -_-;;
자꾸 샛길로 태클거는건 그다지 건전한생각같지 않아보입니다.

자꾸 그런식으로할꺼면 저라도 잠구는데 한표던지겠습니다.

한마디로 말도못하게하는..

------------------------------------
F/OSS bless you... ^^*

fender의 이미지

dummy999 wrote:
움.. 토론하다보면 샛길로 샐수도있는뎅.. 그걸.. -_-;;
자꾸 샛길로 태클거는건 그다지 건전한생각같지 않아보입니다.

자꾸 그런식으로할꺼면 저라도 잠구는데 한표던지겠습니다.

한마디로 말도못하게하는..


누구나 토론하다보면 잠시 옆길로 샐 수 있습니다. 근데 왜 유독 사람들이 dummy999님의 글에만 '태클'을 거는 지 생각해보신 적이 있나요?

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

logout의 이미지

dummy999 wrote:
움.. 토론하다보면 샛길로 샐수도있는뎅.. 그걸.. -_-;;
자꾸 샛길로 태클거는건 그다지 건전한생각같지 않아보입니다.

자꾸 그런식으로할꺼면 저라도 잠구는데 한표던지겠습니다.

한마디로 말도못하게하는..

솔직히 dummy999님의 글은 이제 지루하다 못해 하품까지 나옵니다... 왠만하면 쓸데없는 글은 좀 올리지 마시길.

다른 분들도 dummy999님 글에는 아까운 시간 써 가며 답변을 달 필요가 없지 않나 싶네요. 항상 dummy999님 쓰레드는 플레임 아니면 이소리도 저소리도 아닌 이상한 쪽으로 주제가 흘러가니 말입니다...

"I conduct to live,
I live to compose."
--- Gustav Mahler

angpoo의 이미지

못보던 주젠데 왜 3페이지나 되나 했더니
9월달 그것도 작년의 주제군요.

일정기간 동안 답글이 없는 주제는 답글을 달 수 없도록 했으면 좋겠네요.
링크라는 것도 있으니 연관되는 주제를 올리는데 문제도 없잖아요.

한달 혹은 세달이면 적당하려나...

keizie의 이미지

그럼 제가 이렇게 반론을 쓸 수도 없겠죠. 고인 물은 썩고 바뀌지 않는 정보는 쓰레기가 된다는 걸 아시잖습니까?

mirr의 이미지

음....엄청난 쓰레드군요.....
이런 쓰레드 붙일 시간에 답변수 0인 글들에 답변해 주셨으면 더욱 더 감사해 하는 사람들이 많았을꺼라는
생각도 듭니다 흑..... :P

PS..묶어보기로 해서인지 찾기로 2006을 검색하지 않았다면 어디 새로운 글이 포스팅된건지 몰랐을껍니다 :)

내 마음속의 악마가 자꾸만 나를 부추겨.
늘 해왔던 것에 만족하지 말고 뭔가 불가능해 보이는 것을 하라고 말야.

내 마음속의 악마가 자꾸만 나를 부추겨.
늘 해왔던 것에 만족하지 말고 뭔가 불가능해 보이는 것을 하라고 말야.

keizie의 이미지

이를 테면 새로 시작한 어느 프로젝트에 참여하는 것보다는 그놈 프로젝트의 안정된 모듈에 더 관심을 기울인다고 할까요. 의외로 기존 쓰레드를 살려서 쓰는 것에 대해 별 가치를 두지 않는 분이 많던데, 고만고만한 논의를 양산해봐야 질적으로 나아질 게 없습니다.

전 무플 방지 위원회 사람이 아니라서요. :)

WaterDragon의 이미지

angpoo wrote:
못보던 주젠데 왜 3페이지나 되나 했더니
9월달 그것도 작년의 주제군요.

일정기간 동안 답글이 없는 주제는 답글을 달 수 없도록 했으면 좋겠네요.
링크라는 것도 있으니 연관되는 주제를 올리는데 문제도 없잖아요.

한달 혹은 세달이면 적당하려나...

angpoo님 글 읽고 나서 실수했다는 걸 깨달았습니다. phpbb의 특성을 잊은 채 글을 작성했던 실수는 인정해야겠습니다. 작성했던 글 내용에 대해서는 마지막 부분을 제외하고는 특별히 잘못 작성했다는 생각은 들지 않습니다.

잠그는 데 한 표 던집니다.

kida의 이미지

안녕하세요 유령 키다군 입니다..^^;;

angpoo wrote:
못보던 주젠데 왜 3페이지나 되나 했더니
9월달 그것도 작년의 주제군요.

일정기간 동안 답글이 없는 주제는 답글을 달 수 없도록 했으면 좋겠네요.
링크라는 것도 있으니 연관되는 주제를 올리는데 문제도 없잖아요.

한달 혹은 세달이면 적당하려나...

등록날짜를 잘 보시면 아시겠지만...
아주 옛날주제에 다시 관심을 끌려고 쓸데없는 글자들을 나열하신분은.
이 토론을 개설하신 분이십니다... -.-;

자신의 글에 많은 답글이 달린게 자랑 스러워서일까요..
글쓰신 이유는 모르겠습니다만..
뭐.. 여튼 그렇습니다.;;

안경 미소녀가 좋아~!