리눅스 네이트온 베타테스터인데요.. 설치문제..
글쓴이: s750320y / 작성시간: 수, 2007/08/29 - 1:26오후
X library가 설치가 안되서 컴파일이 안됩니다...
config.log 파일에..
configure:28913: error: Can't find X libraries. Please check your installation and add the correct paths!
이렇게 뜹니다..
참고로, kubuntu(ubuntu)에서의 X library 패키지는 아래와 같습니다.
ii xorg-dev 7.2-0ubuntu11 the X.Org X Window System development librar
ii xserver-xorg-dev 1.2.0-3ubuntu8 X.Org X server -- development files
근데 저는 지금 페도라 7을 사용하고 있는데.. 어떤 패키지를 설치해야하나요..?
Forums:
같은 질문은 한
같은 질문은 한 글타래로 질문하세요. 여러 글타래로 발생시키면 논의가 여러곳에서 이루어지기 때문에 제대로 된 답변을 얻을 수 없습니다.
########### 기운이 솟아나는 티거 호랑이 노래 ###########
폴짝폴짝 폴짝폴짝 비켜나세요. 티거가 나가거든요 폴짝폴짝폴짝~
저기가는 저 푸우 조심하세요~ 바지벗고 다니다가 어흥!!
원래 글에 스팸이
원래 글에 스팸이 잔뜩 붙는 바람에 보기가 좀 그러네요.
원래 글에 달렸던 개발자분의 글을 읽었습니다.
한 때 같은 사무실, 같은 팀에서 일했으니 안면도 꽤 있습니다.
각설하고...
closed beta test ... 참 싫어하는 문구입니다.
이왕 그렇게 하기로 정책을 정했으면, 정책을 따르라고 말하고 싶습니다.
beta 단계면 이미 *배포*를 목적으로 하는 테스트 아닌가요 ?
소스도 없는 마당에,
질문하신 분의 저 애매모호한 글만으로는 추측성 답변이 달릴 수 밖에 없습니다.
어느 분의 말씀대로 x11/xorg devel 에 속하는 수십개의 패키지 전부가 필요할 수도 있고,
libX11-devel 패키지 한개만 필요할 수도 있지요.
마지막으로,
"저도 잘 모르겠으니 KLDP 에 물어보세요"
라는 답변은 "DIY 하셈" 과 정확하게 같은 뜻입니다.
이게 closed beta tester 가 들어야 할 답변이라 생각하고 계신다면, 대단히 실망입니다.
공개 비공개를 떠나서 유지/보수/사용자지원에 대한 어떠한 계획도 가지고 있지 않으며,
앞으로도 계속 그럴 것이다라는 의미니까요.
open source 의 장점은 다 버리고, 단점만 전부 가지고 있는 게 현재 상태인 것 같네요.
OTL
질문자의 애매모호한 글이 프로젝트 자체에 대한 비난의 근거가 되나요?
질문자가 애초에 정보가 부족한 글을 올린 것은 사실입니다. 그 원인이 knateon인 것은 별 상관이 없죠. 네이트온을 빌드하다 나온 에러라는 것을 빼면 그냥 잠깐 스치고 지나갈 '부족한 질문'일 뿐입니다. 네이트온 관련이라서 굳이 더 말씀을 하시는가본데, 베타테스트라고 다 배포를 목적으로 한다고 하시면 안 되죠. 베타에도 클베가 있고 오베가 있는데 클베중인 프로젝트에다 공개되지 않았다고 비난을 하면 말이 안 되지 않습니까.
개발자가 신도 아닌데 자기가 모르는 환경에 대해서 어떻게 일일이 대응을 할 수 있겠습니까? 정확하지 않은 답변을 하는 것보다는 제대로 된 답을 얻을 가능성이 있는 다른 곳으로 유도하는 편이 훨씬 낫죠. 이건 다른 어떤 프로젝트에서도 마찬가지입니다. 사용자층이 이미 두터워서 어떤 환경이든 답이 나올 수 있는 규모가 아닌 바에야 어쩔 수 없는 일입니다. 이게 오픈소스의 단점이라면 단점이겠죠.
그러면 버렸다는 장점은 무엇입니까? 버그 보고도 할 수 있고 원한다면 개발자분과 바로 대화를 할 수도 있습니다. 코딩 능력이 된다면 패치를 제출할 수도 있습니다. 사용/수정/재배포를 오픈소스의 조건으로 봤을 때 클베라서 제한된 재배포를 빼면 사용과 수정은 얼마든지 가능합니다. 뭐가 문제입니까?
어휘력이 부족해서
어휘력이 부족해서 쉽게 쓰지 못했습니다. 사과드립니다.
beta test 라는 것은 "s/w 의 단위 기능" 에 대한 테스트가 아니라 "시스템" 에 대한 테스트입니다.
좁은 의미로 보면 "s/w가 가지고 있는 모든 기능들의 조화로움"에 대한 테스트,
넓게 보면 "s/w의 설치,동작 전반에 관한 유무형의 자원들의 조화로움"에 대한 테스트입니다.
closed beta test 라는 것은,
공개적으로 풀어놓을 경우, 미처 준비되지 못한, 또는 오류가 있는 시스템으로 인해 feedback 자체가 혼란스러워지는 것을 막기 위해 행합니다.
따라서, closed beta test 라는 것을 하기 위해서는 feedback 을 처리할 수 있는 "시스템"이 전제됩니다.
closed beta test 가 끝나면 known bug, trouble shooting 에 대한 문서가 만들어지고, 이 기간동안 활용된 시스템은 사용자지원을 위해 존속됩니다.
open source 는 이러한 과정이 아예 없을 수도 있고, 이보다 더 심한 과정을 거칠 수도 있습니다.
분명한 것은, 개발과정 자체가 open 된다면 그 즉시 무한경쟁 속으로 내던져지게 된다는 겁니다.
무한경쟁 속에서, 수많은 테스트를 거친 open source 는 당연히 품질이 좋습니다. 우월하지 못하다면 도저히 살아남을 수 없는 세계니까요.
어쨌든, 씹을거리가 된 이 s/w 는 개발과정이 open 되지 않았습니다.
- 문제 없습니다.
closed beta test 를 한답니다.
- 불만족스럽기는 합니다만, 사정이 있겠거니라고 생각했습니다.
테스터의 feedback 을 처리할 시스템이 없답니다.
- 장난하는거죠. 짜증스러운.
분명히 말씀드리는 데, 질문자의 애매모호한 질문글은 핵심적인 쟁점입니다.
애초에 저 질문을 받았던 개발자가 어떤 답변을 들려줬길래 저런 식의 애매모한 질문이 KLDP 에 올라오게 됐는지... 눈 앞에서 본 것처럼 선명합니다.
적어도 제한적인 환경에서 소수의 테스터를 직접 모집해서 뭔가를 테스트하는 도중에는, 어떤 개발자도, 어떤 시스템도 그러한 답변을 테스터에게 해서는 안됩니다. 테스터는 개발에 도움을 주는 개발자 그룹에 속한 팀원입니다. 외부에서 모집한 무료 자원봉사 테스터라 무시하는 게 아니라면요.
config.log 의 해당부분 일부, 또는 파일 전부를 전송받아 conftest 컴파일 실패의 이유를 알아내는 게 어렵습니까 ?
헤더 혹은 모듈 파일을 포함한 rpm 패키지를 찾기위해 rpmfind 를 방문해서 검색하는 게 어렵습니까 ?
도저히 모르겠으면 개발진 혹은 시스템의 다른 누군가가 직접 KLDP 에 글을 올리던가,
이것도 저것도 다 귀찮으면, 이 내용을 테스터에게 알려주기라도 하면 되지 않겠습니까 ?
도대체 뭘 테스트하려고 closed beta test 씩이나 하는 건가요 ?
open source 의 단점이라면,
- 사용자 지원의 정도
- 개발(배포)과정의 혼란스러움
이 천차만별이라는 겁니다.
익히 아시다시피, 이 단점들은 open source 의 장점 때문에 생깁니다.
씹을 거리가 된 이 s/w 에서는
- 사용자(테스터) 지원이 없고,
- 개발(배포)과정의 혼란스러움이 극에 다다라 있습니다.
어느 누구도 s/w 의 개발과정 자체에 대해 트집을 잡은 적은 없습니다.
closed 로 개발하고, closed test 를 하겠다... 누가 뭐라 하겠습니까. 독점적인 지위를 가지고 있는데.
짜증이 나는 이유는.
소위 closed beta test 에 참여한 테스터의 feedback 에 대해,
아무런 reaction 없이 forward(KLDP) 로 대응한 개발진 혹은 시스템 때문입니다.
짜증을 참지 못해 이런 글을 적는 이유는.
그 개발진 혹은 시스템을 비판한 글에 대해, 개발자 분이 직접 단 댓글의 내용이 어처구니없어서 입니다.
이만하면 회사의 정책이나 forward(KLDP) 를 비난하고 있는 게 아니라는 것을 이해하셨을 것으로 믿습니다.
OTL
:-)
이 글을 마지막으로 더이상 답글을 안 달겠습니다.
( 저도 일을 해야 하니까요~ )
내용이 공감이 안되는군요. 추측이 많아서 그런것 같습니다.
한마디만 할께요~
오픈소스가 되면 말만이 아닌 행동으로 보여주셨으면 하는 바램이 듭니다.
---
Jabber: lum0320@jabber.org
Lum7671's Weblog
설명 감사합니다.
어떤 논리로 당해 프로젝트에 대한 비난이 나왔는지 확실히 이해했습니다. 지원이 없는 프로젝트라면 욕 먹을 만하다고 생각합니다. 납득하게 해주셔서 고맙습니다.
하지만 설명하신 논리구조의 깔끔함에 비해 투입된 전제가 잘못된 것으로 보입니다. '눈에 선히 보인다'고 하신 그 상황까지는 아니기 때문입니다. 이를 테면 지레짐작으로 비약을 하시고 논리를 진행하셔서 (과정은 올바른데) 결론이 틀린 셈이네요. :) 외부에는 전혀 노출이 없는 상황에서 불거진 하나의 사례가 전체를 판단하는 근거가 되지 않으면 좋겠습니다.
초반에 메일로만 연락을 받다가, 제 경우엔 아예 네이트온에 개발자분과 다른 테스터 몇 분을 등록하기도 했습니다. 그때부터 얘기가 나왔는데 결국 최근에 맨티스가 제공되어 쓰고 있습니다. 방금 받은 메일에는 (가능하면) 9월 중으로, (가능하면) kldp.net에 들어 앉는 게 바람이라고 하니 설사 계획대로 되지 않더라도 프로젝트의 진행은 (기대치에 가깝게) 점점 나아질 거라고 봅니다.
일개 테스터지만, knateon이 단순히 메신저의 한 종류가 아니라 국내 대기업의 향후 판단에 영향을 줄 수 있는 프로젝트라고 보고, 장하게 생각하고 있습니다. 프로젝트 진행이 서툴고 낯선 것은 사실입니다만 단점을 들어 공격하기보다는, 회사에서 프로젝트를 진행하는 분들이 신이 나서 '자 공개하니까 이렇게 좋지 않느냐'고 회사의 다른 사람들을 설득할 수 있도록 추켜주는 게 서로에게 바람직하지 않나 생각합니다.
음...
누구신가요?
같은 사무실에서 같은 팀으로 일했다는데...
이런글을 쓸만한 분이 누구인지 도무지 생각이 안나는군요.
---
궁금한건 궁금한거고,
저도 클로우즈드 베타, 오픈 베타는 현재 팀에 와서 처음으로 접하는 겁니다.
회사에서 완성도를 높이는 방법이라고 생각해 주세요.
( 정확히 "사내QA 1차 - 클로우즈드 베타 - 사내QA 2차 - 오픈 베타 - 정식(?)" 로 진행한다고 합니다. )
물론, 오픈소스는 웬만하면 오픈해서 같이 만들어가는게 시원시원하고 좋다고 생각하지만,
(일반 end-user 의 마인드와 차이가 있다는것을 인정합니다.)
회사에서 오픈소스에 익숙한 분들이 거의 없습니다. 사내에서도 거의 처음 시도이니 그렇겠지요.
기존에 윈도우즈 어플리케이션 기획자분은 이해 못할 분도 많습니다.
저는 급진적인 것은 되도록 피합니다. 논의를 해서 되도록 회사의 룰을 따르려고 합니다.
GPL역시 강요를 할 수 없습니다. 하지만, 그렇게 되었으면 좋겠다고 얘기를 하지요.
너무 소극적인게 아니냐고 하실 분들도 있겠지만...
점점 좋아질 겁니다. 점점...
---
Jabber: lum0320@jabber.org
Lum7671's Weblog
해당 글타래는
해당 글타래는 확인하였습니다. 일단 앞뒤 상황에 대한 설명, 정확하게는 어디에 먼저 피드백이 되었는데 이 부분에 대해서 해결이 되지 않았기 때문에 여기에 문의를 드립니다 라던지 하는 내용들이 딱히 없었기 때문에 그렇게 말씀을 드린것입니다. 만일 그러한 내용이 언급이 되었다면 역시 이야기가 달라지겠지요.
그리고 베타테스트라는것 자체가 어느정도 개발자가 모든 환경을 접하고 확인할 수 없기에 사용자들의 다양한 환경에 해당 프로그램을 노출시켜 발생하는 문제가 있는지 등을 확인하는것이 그 기본 내용입니다. 그것이 오픈이던 closed던 그건 지금 하려는 이야기와는 관계가 없으므로 넘어가고, 일단 그렇게 베타테스트가 이루어지고, 그 과정에서 설치가 안되던, 설치 후 실행이 안되던, 실행은 되는데 사용상에 문제가 있던, 베타테스터는 이러한 환경에서 이러이러한 것을 해보았는데 안됩니다. 라고 개발자에게 피드백을 하면 그만입니다.
문제 해결의 단계는 실제로 베타테스터 단계에서 이루어지는게 아니라 베타테스터가 피드백을 하면 개발자 입장에서 해결이 되어야 합니다. 하다못해 개발자가 특정 플랫폼에 대한 이해가 부족하면 개발자가 해당 커뮤니티에 문의를 하던, 배포판 제작사에 문의를 하던 문의를 하고 답을 보내주면 될 일입니다. 물론 많은 수의 오픈소스 툴처럼 베타테스터가 충분한 능력이 된다면야 "현재 내가 사용중인 환경에서는 이러이러한 문제점이 있는데, 내가 볼때는 이 부분은 이렇게 해결하면 좋겠다" 라는 식으로 개발팀에게 제안을 할 수도 있겠습니다만, 대부분 그 정도까지 바라는것은 좀 무리가 있는 부분이지요. 단지 문제가 있다 정도로만 피드백 받아도 충분합니다.
그리고 실제로 해당 툴이 wide하게 오픈되어 다양한 사용자들이 쓸 수 있는 환경이 된다면, 저같은 경우는 질문이 올라올때 제가 직접 해보지 않고도 손쉽게 답변할 수 있는 질문이 아닌 경우 대부분 동일한 환경을 구성해서 테스트를 해 봅니다. 하지만 지금같이 동일한 테스트가 불가능한 상황에서 페도라에서 컴파일하는데 무슨 에러문구에 ubuntu 운운하는 문구부터 나오니 일단 난감하고, 대략 보니 x관련 라이브러리가 없는듯 싶고, 사용자분 또한 거기에 대한 인식을 하고 계신것으로 판단되어 일단 단순히 한두개 정도의 패키지만 설치한다고 해결될 문제가 아닌듯 하여 일단은 x관련 라이브러리 패키지 그룹 전체를 설치하여 테스트해 보실것을 말씀을 드렸습니다.
뭐 단순 패키지 단위 설치가 아닌 사용자가 컴파일을 해서 실행을 해 보아야 하는 정도라면 일단 사용자에게 해당 툴과 관련된 개발 라이브러리는 빼놓지 말고 가지고 있어야 정확한 테스트가 가능하기 때문이지요. 그리고 사용자는 그 내용 가지고 한번 테스트 해 보고, 만일 잘 동작한다면 나중에 개발자에게 "이러이러한 문제가 있었는데 이렇게 이렇게 해서 컴파일이 되어 해결이 되었습니다" 라는 정도로 피드백을 하고, 개발자 측면에서는 나중에 배포할때까지 소스레벨로 배포하실 작정은 아니실테니 패키지 배포를 하실테고, 그러면 그러한 부분에 대해서 패키지 배포용 빌드시 그런 부분을 받아들여 손쉽게 패키지 빌드를 하고 배포를 할 수 있는 수준에 이르게 되겠지요.
그런데 이게 뭐 그렇게 문제가 되어서 지금 말이 많아지는지 사실 이해를 하지 못하겠군요. 일단 이러한 부분이 오픈소스 개발의 자연스러운 흐름 중 하나이기도 합니다.
그런데 거기에서 "아는내용이면 성심성의껏 답변해주면 됩니다" 라는 말이 나오다니..물론 성심성의껏 답변을 안한것도 아닙니다만..그 이전에 무슨 베타테스트 레벨이라고 언급을 하시길래, 베타테스트 레벨이면 이러이러한 방법론을 통하여 테스트가 이루어지니 먼저 이렇게 피드백을 해보는것은 어떻습니까? 라는 식으로 제안을 드린것이지 그게 왜 KLDP에 질문을 하냐 라는 정도의 레벨로 보이시는건가요? 그걸 컴파일 중 문제가 생겨서 KLDP에 문의를 하면 뭐라고 답변할거냐니요? 아무래도 오픈소스 개발 방법론의 흐름에 대한 파악을 먼저 하시는게 좋을듯 싶으신데요? 서로간의 이해의 차이가 있을수는 있습니다만, 그런 부분을 이런식으로 단순하게 생각하시고 넘겨짚으시면 오픈소스 방식으로 개발하는데 있어서는 많이 곤란합니다. 이 곳에서 많은 답변을 해 왔습니다만, 이번건은 정말 기분이 많이 상하는군요.
########### 기운이 솟아나는 티거 호랑이 노래 ###########
폴짝폴짝 폴짝폴짝 비켜나세요. 티거가 나가거든요 폴짝폴짝폴짝~
저기가는 저 푸우 조심하세요~ 바지벗고 다니다가 어흥!!
우선, 맘 상하셨다니 죄송합니다..
어느정도 서로 오해가 있는 부분이 있는것 같습니다.
저도 질문하신 분이 몇번의 메일이 오가면서 그분에 대한 파악을 어느정도 한 상태여서
질문에 대한 생각을 처음 보시는 분들입장에서 생각 못한게 사실입니다.
( 처음 보시는 분들은 질문이 이상했을 수 있어 보입니다. )
전에도 글을 썼지만, 에러 내용을 보고 KLDP에 문의를 해보는게 좋겠다고 말씀을 드렸습니다.
(주위에 Fedora를 사용하시는 분이 안계시는군요.)
다음은 질문자 분에게 보낸 메일 입니다.
제가 무리해서 글을 쓴것은 제가 KLDP에 문의를 해보라고 부탁드렸기 때문이고,
혹시, 클베를 하고 있는 knateon이기 때문에 반감을 갖고 글을 쓰신게 아닌가? 여서 였습니다.
다시한번 맘 상하셨다니 미안하게 되었습니다.
서로 오해가 있었던 부분이니, 금방 떨쳐내시길 바랍니다. :-)
---
Jabber: lum0320@jabber.org
Lum7671's Weblog
뭐 저야
뭐 저야 베타테스트를 클로즈로 하던 오픈으로 하던지 상관은 없습니다.
일단 위에서 언급은 하지 않았습니다만, 어떠한 문제가 발생하였을때 커뮤니티의 도움을 받아서 문제를 해결하려는 과정을 좀 더 순탄하게 가져가시려면 클로즈 베타보다는 오픈 베타과정이 좀 더 올바른 과정으로 보입니다. 그렇지 않을경우 오픈 커뮤니티에 질문이 올라올 경우 그에 대한 제대로 된 테스트를 하기 어렵기 때문에 명확한 답을 커뮤니티에서 기대하기 어렵게 됩니다.
혹시 이번 Closed Beta과정에서 베타 테스터들간에 의사 소통을 할 수 있는 커뮤니티가 존재하는지요? 그러한 부분을 내부적으로라도 가지고 계시거나, 하다못해 내부적으로 간단한 메일링 리스트 정도를 통해서라도 의사 소통이 가능하다면, 비슷한 문제를 겪고 있는 베타 테스터간의 의사 교환으로 생각보다 좀 더 손쉽게 문제를 해결하실 수 있을듯 합니다. 의사소통 없는 베타테스트는 서로간의 중복된 트러블을 트래킹하게 되는 문제점을 가지게 됩니다. 일단 다른 사람이 이 부분을 찾았다면 "저도 이러한 문제가 있네요" 라던지 "저는 이렇게 해결이 되었네요" 라는 식으로 피드백을 받고, 다른 사용자들은 그 문제점 이외의 다른 문제점을 찾는데 좀 더 집중할 수 있는 환경이 마련되면 베타테스트를 하는데 있어서 좀 더 많은, 양질의 결과물을 도출하실 수 있습니다.
그래서 해외쪽에서는 베타테스트 과정부터 버그질라 등의 버그 트랙백 시스템을 도입하여 문제를 해결하곤 하지요. 아직 국내 개발문화에서 버그질라가 익숙한 편은 아니기 때문에 많이 어려움을 느끼시리라 생각됩니다만 한국 사용자들에게 좀 더 사용이 편리한 버그 트랙백 시스템을 간단하게나마 개발하여 사용하시면 좀 더 도움이 되실 듯 합니다.
뭐 이런 말씀을 드리는 것 역시, 이번 질의 문제를 보고 나서 제가 내부적인 부분까지 알지는 못하겠으나. 작게나마 이래저래 지금의 리눅스 네이트온 개발과정에서 나름데로 느껴지는 필이 있어 간단하게나마 적어보는 것입니다. 기분 나쁘게 듣지 마시고 그냥 간단한 조언 정도로 여겨주셨으면 합니다.
감사합니다.
########### 기운이 솟아나는 티거 호랑이 노래 ###########
폴짝폴짝 폴짝폴짝 비켜나세요. 티거가 나가거든요 폴짝폴짝폴짝~
저기가는 저 푸우 조심하세요~ 바지벗고 다니다가 어흥!!
:-)
아는 분이 맨티스를 제공해 주셔서 그걸 사용합니다. :-)
관심 갖고 글 써주셔서 감사드리고요.
리눅스 네이트온이 의미있는 일이 될 수 있도록 관심 부탁드립니다.
개인적으로,
인터넷뱅킹, 오피스, 게임, 메신저
이렇게 리눅스가 데스크탑으로 일반 사람들에게 불편하다고 생각되는건데요.
오피스는 어느정도 오픈오피스로 해결, (까다로운 End User는 해결을 못하겠죠. 상용 아래한글? )
게임은 무시, ( End User는 무시할 수 없는 분이 더 많겠지만... 컴퓨터 가지고 뭐하라고?? 하시겠죠.)
메신저는 MSN, 네이트온
그럼, 인터넷 뱅킹만 남는군요.
개발이 어느정도 부자연스럽거나, 답답해 보일 수 있습니다.
그래도, 클베 사용자에게 소스를 제공하고 하면서 이렇게 진행된다는것만으로도
저는 기쁘게 생각하고 있습니다.
오픈베타에 오픈소스가 될것이니, 그때 많은 가르침 부탁드리겠습니다. :-)
---
Jabber: lum0320@jabber.org
Lum7671's Weblog
외부에서 볼때는 많이 부자연스럽고 답답하니까
우리 일단 장풍 몇대 맞고 시작해보아요~ (~^-^)~oooㅇㅇㅇ )/-A-)/
########### 기운이 솟아나는 티거 호랑이 노래 ###########
폴짝폴짝 폴짝폴짝 비켜나세요. 티거가 나가거든요 폴짝폴짝폴짝~
저기가는 저 푸우 조심하세요~ 바지벗고 다니다가 어흥!!
중요한 것은..
이 원칙이 '조직'에도 통하는 가는 모르겟씁니다. 칭찬하고 잘 된 부분들을 추켜 세우며 잘못된 부분들을 언급하지 않는 것이 진정 긍정적인 방향으로 이끌어 가는 방법이라고 하는데, 이게 일반적으로 개인에게는 먹히는 원칙이라고 알고 잇씁니다. 물론 쉽지 않겟죠. 지켜 보은 입장에서 그렇게 할 수 있다는 겁니다. 이 원칙이 '조직'에도 통하는 거라면 부정적인 것들을 찝어 뭐라고 하기 보다는 긍정적인 부분들 자체를 끝없이 추켜 세워 주는게 필요하지 않나 싶긴 합니다.
----
Lee Yeosong(이여송 사도요한)
E-Mail: yeosong@gmail.com
HomePage: http://lys.lecl.net:88/
Wiki(Read-Only): http://lys.lecl.net:88/wiki/
Blog: http://lys.lecl.net:88/blog
MSN: ysnglee2000@hotmail.com
----
절이 싫으면 중이 떠나는 것이 아니라, 절이 싫으면 중이 절을 부숴야 한다.
때때
사람천사
댓글 달기