리눅스, 닷넷을 끌어안아라

geekforum의 이미지

http://www.zdnet.co.kr의 기사내용 일부입니다. 전체 내용은 관련 링크를 참조하십시오.

---
필자가 지난 번 컬럼에서 지적했듯이 MS가 추진중인 닷넷 프로젝트는 MS는 물론 비MS 플랫폼에서도 공동으로 사용할 수 있는 표준 개발 틀로 성장할 것이라고 생각한다. 하지만 닷넷의 성장이 꼴보기 싫어서 키보드를 집어던지고 히말라야에서 셀파가 되기로 작정하지 않은 이상 닷넷같은 공통 개발 틀을 중심으로 전세계가 통합되면 얼마나 많은 이점이 있을 것인지 한번 곰곰이 생각해 보기 바란다. 닷넷을 닷넷에서는 다양한 프로그램 언어를 지원하고 있다는 점을 강조하는 차원에서 '소수 프로그램 언어의 구세주'라고 주장하는 바를 따져보자. 이처럼 다양한 언어를 지원하는 특성 때문에 닷넷은 리눅스를 포함해 많은 비MS 플랫폼과 응용 프로그램에게 행운을 가져다 줄 수 있을 것이다.

1. 닷넷은 여러 비MS 플랫폼이 더 큰 윈도우 개발 공동체에 연결되도록 해준다. 이렇게 되면 이들 플랫폼에서 일하게 될 개발자의 숫자도 증가될 것이다. 아래에 있는 글은 시미안의 창설자 미구엘 드 이카자가 생각하는 왜 리눅스에 닷넷을 설치해야 하는지에 대한 글이다.

- 윈도우 개발자들은 리눅스를 위한 코드를 작성할 수 있다.

- 개발자들을 윈도우 세계에서 리눅스 플랫폼으로 이끌어오는 것이 쉬워진다.

- 훈련용 교재나 교육용 교재, 문서들, 여러 가지 유용한 정보와 도움말 등이 이미 많이 나와 있다. 이것들을 이용하자.

다른 말로 하자면, 윈도우 개발자들이 리눅스를 위해 프로그램을 작성하는 것이 쉽다면 그들은 리눅스를 위한 프로그래밍을 할 것이다. 전혀 다른 API를 재교육 받는 것조차 개발자들은 개의치 않을 것이다.

게다가 닷넷을 받아들임으로써 다른 플랫폼들은 MS와 다른 여러 회사들이 닷넷 참고 문헌과 교육에 투자한 수십 억 달러의 비용을 덩달아 이용하게 되는 셈이다. 오랫동안 맥과 BeOS의 개발자였으며 '페퍼'라는 교재의 편집자였던 마텐 헤켈만이 최근에 한 인터뷰에서 말했듯이 MS의 문서들은 정말 괜찮은 내용을 담고 있다. MS는 다른 회사들이 하지 못하는 방식으로 개발자들의 욕구를 충족시켜준다. 이런 투자를 이용하는 것은 사업적인 센스가 아닌가. 사실 이런 투자는 사실 다른 플랫폼에서 이득을 볼 수 있는 공짜 돈이다.

결론적으로 비MS의 입장에서는 닷넷이 개발 비용을 절약해주는 셈이다. 저렴한 비용에다가 윈도우 개발자들이 넘어가야 했던 장애물도 많이 없어지기 때문에 더 많은 애플리케이션이 나올 수 있는 토양을 닦을 수 있다는 뜻이다. 네트워크 효과가 소비자들을 윈도우로 계속해서 유인하는 것이라면, 그 네트워크에 연결해 소비자들을 리눅스같은 플랫폼에 대해서도 한번쯤 고려하게끔 할 수 있는 가능성이 더 많아지는 것이다.

2. 비MS 플랫폼에서 MS 애플리케이션을 지원하는 것이 더 쉬워진다. 당신이 좋든 싫든 MS 애플리케이션은 현재 나와있는 소프트웨어 가운데 가장 인기 있는 제품이다. MS는 자사의 제품 가운데 대부분을 닷넷으로 전환할 계획이다. 그렇게만 되면, 그들이 비MS 플랫폼에서도 그것들을 사용할 수 있는 기회가 생기는 것이다. 그렇게 되면, 애플리케이션들이 윈도우 고유의 코드와도 호환될 수 있고, 또 윈도우에서만 쓸 수 있는 프로그램을 사용할 수 있게 될지도 모른다. 따라서 오피스를 완전히 사용할 수 없는 비표준 기능을 제공하는 회사들도 시장에 참여할 수 있는 기회를...
---

Ximian의 창설자 미구엘 드 이카자가 생각하는 왜 리눅스에 닷넷을 설치해야 하는지에 대한 글을 읽은 적이 있습니다. 여러분은 이것에 대해 어떻게 생각하시는지...

익명 사용자의 이미지

썬-MS「하늘이 준 기회를 놓쳤다!」



MS가 썬의 자바를 퇴출시키는 작업이 거의 끝났다. 기업용 개발에 있어서 종종 자바가 필요한 경우를 제외하고는, MS의 모든 개발 계획에 있어서 자바는 포함돼 있지 않다.

John Carroll (Special to ZDNet) 2002/10/18


이것은 MS가 자바 기술 구현에 관해서 3년 6개월 동안 치룬 법정 투쟁의 결과다. 사람들은 썬이 법정 싸움을 성공적으로 끝냄으로써, MS가 자바의 WORA(Write Once, Run Anywhere) 약속을 오염시키는 것으로부터 세계를 구했다고 믿을 수도 있다.

사실 썬이 성취한 것이라곤 윈도우에서 가상머신(VM) 스타일의 기술을 무효화시킴으로써 "오염된" 자바(닷넷)가 등장할 수 있는 시장 기회를 없앤 것뿐이다.

썬은 MS가 계획대로 자바를 요리하게 방치해 개발자들이 스스로 선택을 하도록 하는 편이 나았을 것이다. 오히려 썬은 MS가 자바에 투자하고 마케팅에 쏟아부을 자원을 거부한 꼴이 됐다.

자바는 1996년 발표됐을 당시 MS를 포함해 컴퓨터 산업계 전반에 걸쳐 많은 환영을 받았다. 이 시기의 뉴스들은 MS 개발자들이 자바에 얼마나 열광적이었는지 자세히 적고 있다.

특히 MS R&D는 자바를 이용해 흥미있는 많은 일들을 했다. 이런 연구가 당시로서는 가장 빠른 자바 VM을 탄생시켰다. MS 개발도구인 J++는 자바 통합 개발 환경(IDE) 중에 가장 뛰어난 것중 하나로 널리 인정됐다. MS의 투자와 지원을 등에 업은 자바는 미래 소프트웨어 아키텍처라는 위치를 거의 굳힌듯 보였다.

최소한 썬의 입장에서 일이 어긋나기 시작한 것은 MS가 자바 VM에 추가 기능을 부가하고, 맘에 들지 않는 기능을 제거하려고 했을 때였다. 한 가지 예는 자바 애플리케이션이 운영체제의 고유 함수들을 호출할 수 있게 하는 JNI를 MS의 VM이 지원하지 않는다는 것이었다.

MS는 J/다이렉트라는 고유의 기술을 개발해 이러한 함수 호출이 더욱 쉽도록 했다(JNI의 harness 코드가 필요없었다). MS는 RMI를 자사의 클래스 라이브러리에 추가하지 않기로 결정했다.

RMI는 1997년 2월에 JDK 1.1과 함께 발표된 기술로 원격 객체를 호출하는 자바의 표준 아키텍처였다. MS는 또한 자바 언어에 기능을 추가해 '위임자(delegates)'를 두어 이벤트 통보를 효율적으로 하게 했다(이것은 현재 C#에서 찾을 수 있는 기능이다).

분쟁의 핵심
썬은 기저가 되는 운영체제에 상관없이 어떠한 VM에서도 모든 애플리케이션이 동작한다는 것에 자바의 중요성이 있다고 믿었다. 이러한 WORA 기능은 모든 플랫폼을 자바를 중심으로 조직된 소프트웨어 시장으로 편입시키려는 목적을 가졌다. 즉 인기가 없는 플랫폼에 좀더 많은 애플리케이션을 공급함과 동시에 윈도우가 쥐고 있던 애플리케이션상의 이점을 침식하려는 의도였다.

MS는 WORA 기능에 관해 다른 계획을 갖고 있었다. 점증하는 컴퓨팅 기기들의 네트워크를 위한 제품을 생산하는 소프트웨어 업체로서 어떤 기기에서도 동작하는 애플리케이션을 한 번만 작성한다는 것은 도움이 됐을 것이다.

또한 네트워크로 다운로드받은 코드들의 보안은 보장될 수 없었다. 이로 인해 스스로를 기술하는 자바의 '바이트코드' 포맷이 가진 보안 능력이 더욱 주목을 끌었다. 자바는 또한 고유 코드 개발을 개선한 것으로 생산성을 증가시키고, 버그가 없는 안전한 코드를 제작하기가 쉽다.

요약하면 자바는 소프트웨어 개발과정에서 많은 것을 추가할 수 있었는데, 세계에서 가장 큰 소프트웨어 기업인 MS로서는 분명 이익이 되는 일이었다.

그러나 MS는 시장에서 자사 제품을 차별화시키지 못한다는 사실에 흥미를 잃었다. 결국 차별화란 측면에서 MS의 VM에 애플리케이션들로 하여금 고유 코드(즉 윈도우 API)를 쉽게 호출할 수 있도록 하는 기능을 J/다이렉트를 이용해 추가했다.

또한 J/다이렉트 위에서 작성됐으며 WFC(Windows Foundation Classes)라고 불린 완전한 WIN32 API를 보다 잘 표현하는 윈도우 클래스 라이브러리도 제작했다.

이로 인해 윈도우 애플리케이션의 작성이 쉬워졌지만 어떤 플랫폼에서도 자바가 완전히 동일해야 한다는 썬의 비전과는 상충됐다.

썬은 소송을 제기했으며 결국 이겼다. 결과적으로 MS는 미래의 윈도우에서 자바를 포기했다.

상식적으로 생각하면 이러한 결과는 불가피했다. 그러나 과연 그럴까?

상이한 접근법
썬의 일차적인 목표가 완벽한 크로스 플랫폼 지원을 위해 일탈을 제한하는 것이었거나 아니면 전세계에서 가장 큰 소프트웨어 기업이 크로스 플랫폼 지원을 한다는 서명을 확실하게 받을 수 있었더라면(비록 그 회사가 실제로는 그런 결심을 하지 않았다고 하더라도)?

썬이 "좋다. 당신 회사의 VM에 특정한 기능을 추가하는 것은 좋다. 타당한 정도의 핵심 VM 기능과 라이브러리를 지원한다면 말이다. 그리고 VM 코어에 더해진 부가 기능들은 자바 커뮤니티에 환원돼 다른 구현에도 포함될 수 있도록 한다면 말이다"라고 말했으면 어땠을까?

다시 말해 핵심이 지원됨으로써 개발자들이 일관성있는 크로스 플랫폼 기준선을 갖도록 해야 한다. 그러나 원하는 기능은 무엇이든 추가할 수 있다. 타협의 여지가 있었다.

MS는 자사 VM에서 삭제했던 기능중 일부를 지원해야만 했겠지만, 그밖에 원하는 기능도 자유롭게 추가할 수 있었을 것이고, 심지어는 바이트코드 확장도 포함될 수 있었을 것이다.

호환성 측면에서 MS는 이미 필요한 위치에 서있었다. 최근 기사에서 래리 셀처가 시사한 바와 같이 실험결과는 MS VM이 가장 호환이 잘되는 자바 구현이었다는 것을 나타냈다.

순수 자바 애플리케이션들은 고유 함수 호출을 어차피 못할 것이고, 썬은 분명히 MS가 RMI(심지어 JNI)도 포함하도록 할 수 있었다. 자바 VM을 확장시킬 수 있는 자유의 반대급부로 말이다.

MS VM의 확장 기능을 자바 커뮤니티에 공개하는 문제에 있어서 썬이 요구했다면 MS가 긍정적으로 고려했을 것이란 증거가 있다. 다음은 자바월드 1999년 7월호의 기사이다.

MS는 최근 자바 통합 기술(J/다이렉트, 자바/COM, 위임자)을 개발도구 기업들에게 공개해 이들이 자사의 컴파일러와 VM에 이들 기술을 적용시키게 할 의사가 있다고 밝힘으로써 산업계 종사자들을 놀라게 했다. 이러한 움직임은 뉴워드와 같은 개발자에게 있어서 놀라운 것은 아니다. 그는 자바를 공개하는 것은 필수 불가결하다고 믿는 사람이다.

"MS는 썬이 거부한 것을 하고 있다. 즉 JVM을 모두에게 공개하고 볼 수 있도록 하는 일 말이다. 솔직히 말해 MS 중심적 사고를 가진 일부 개발자들은 MS VM 이외에서는 MS 고유 기능을 사용할 수 없다는 사실에 분노했다. 이것은 자바 로비(자바 온라인 공동체)에게 분명한 혼동을 주었다"고 뉴워드는 말했다.

물론 자바는 썬의 고유 기술이라고 지적할 사람들이 있을 것이다. 따라서 썬이 어떤 기능이 포함될지 결정할 수 있도록 말이다. 그 말이 사실이긴 하지만 썬의 목표가 비MS 플랫폼에서 동작하는 애플리케이션의 숫자를 확대시키는 것이었다면, 사업적으로는 별 의미가 없는 일이다. 썬은 법정 소송 대신 MS의 기세를 이용했다면 자기 목표를 달성하는데 더 유리했을 것이다.

뉴워드가 시사한 바와 같이 심지어 윈도우-중심의 개발자들도 크로스 플랫폼을 원했다. 썬은 MS가 제공하지 않는 것을 대신 제공함으로써 이러한 수요를 이용할 수 있었을 것이다.

어떤 형태로든 자바를 이미 사용하고 있던 이러한 윈도우 개발자들을 설득해서 진정한 크로스 플랫폼인 자바를 사용하도록 하는 것은 쉬웠을 것이다. 더욱이 MS VM의 확장 기능들을 복제할 수 있었다면 윈도우 개발자들은 다른 플랫폼용으로 프로그램을 제작하기 위해 자신들이 MS VM에서 선호한 기능들을 희생할 필요도 없었을 것이다.

뉴질랜드의 분자 생물 소프트웨어과 서비스 회사인 제나믹스(Genamics)의 수석 자바 개발자인 벤 알바하리는 썬에게 해주고 싶은 말이 있다. "당신들은 순수 자바에서 VJ++로 옮기는 사람보다 더 많은 사람이 윈도우 개발 도구에서 VJ++로 옮기는 것을 중단시켰다. 오염된 자바라 할지라도 아예 안쓰는 것보다는 자바를 사용하는 것이 낫다. 컴퓨터들이 충분히 빨라지고 순수 자바 라이브러리가 개선된다면 사람들은 순수 자바로 옮기기 시작할 것이다. 당신들은 이러한 과정을 지체시켰을 뿐이다. 뿐만 아니라 MS에게 진정으로 오염된 자바 클론의 구현이라는 선례를 MS에게 선사했다. 이는 순수 자바에게 있어서 진정으로 장기간에 걸친 위협이 될 것이다.(자바월드, 7월호)"

알바하리는 얼마나 선견지명이 뛰어난 사람이었는가?

결론
썬의 실수는 다방면에 걸쳐있다. 부분적으로는 개발자들이 크로스 플랫폼 자바와 특정 플랫폼에 묶여버린 자바를 구분하지 못할 것이라는 믿음의 결여로 설명될 수도 있다. 자바월드 기사가 시사하듯 MS 중심적인 개발자들은 MS VM에 존재한 특정 기능들이 다른 VM에도 존재하길 바랬다. 개발자들은 이러한 추가기능을 원하지 않는다고 말하지 "않았다". 단지 그들은 크로스 플랫폼이 있었으면 하고 바랬을 뿐이다.

이는 몇 가지 사실을 드러낸다. 첫째 개발자들은 크로스 플랫폼 자바와 특정 플랫폼용 자바를 구분할 수 있다. 둘째, 윈도우 개발자중에 크로스 플랫폼 제품을 원하는 수요가 있었다. 썬은 이러한 수요를 자사의 고유 라이브러리나 MS 라이브러리를 복제해 충족시킬 수 있었다. 엑시미안이 닷넷 프레임워크에서 하는 작업처럼 말이다.

셋째, MS는 개발자들이 흥미를 느낀 자바에 관한 아이디어를 가졌었다. MS는 자신들이 추가한 VM 기능을 좀더 폭넓은 자바 커뮤니티에 공개할 의사가 있었음을 증명했다. 썬은 이러한 공짜 R&D를 이용해 자바 플랫폼을 밀어줄 수 있었다.

썬의 실수는 또 소프트웨어 시장에서 MS의 중요성을 간과한 것을 포함한다. 세계에서 가장 인기있는 소프트웨어 제품을 생산하는 업체로서 MS가 그들 자신의 제품에서 특정 기술을 지원하기로 결정했다는 것은 그 기술의 성패를 결정한다.

더욱이 MS는 윈도우 제작사로서 윈도우 개발자들에게 상당한 영향력을 행사한다. MS는 윈도우에서 동작하는 가장 인기있는 소프트웨어 제품을 제작했다. MS는 윈도우용 개발 도구의 우수한 벤더이다. MS는 윈도우 개발자들을 위한 정보원이다(MSDN, MS 프레스 등).

MS가 특정 기술을 사용하도록 확신시킨다면 윈도우 개발자들을 그 기술로 유인하기가 훨씬 쉬워진다. 대다수 개발자들이 윈도우용 프로그램을 작성한다는 사실을 고려하면 이는 중요한 것이다.

썬은 잠재적으로 크로스 플랫폼의 가능성이 있는 인프라스트럭처에 MS가 서명하도록 집중했어야만 했다. 비록 MS가 완벽한 크로스 플랫폼 지원을 결심하지 않았더라도 말이다. MS는 기술세계에서 자사가 가진 상당한 능력을 자바 플랫폼을 대중화하는데 사용했을 것이며, 윈도우 개발자들로 하여금 자바 기술에 익숙해지도록 했을 것이다.

VM 환경의 개념을 이해하는 것은 API를 배우는 것보다 훨씬 많은 노력을 필요로 한다. 또한 다른 플랫폼으로 개발자들을 유인하는 것은 훨씬 쉬웠을 것이다.

썬은 MS가 기술 방향을 결정하는데 있어서 영향력을 행사할 기회를 가졌었다. 비록 자바에 대해서 썬이 좀더 적은 통제력을 갖게 됐을지라도 좀더 큰 영향력을 얻을 기회가 있었다.

대신에 썬은 MS가 상당한 자원을 썬이 통제할 수 없는 기술에 적용하도록 보증했다. 필자 생각이 옳다면, 그리고 닷넷이 크로스 플랫폼 통일을 위한 기술이 되어 "세계를 정복한다면", 썬의 유연성 부족은 전략적 실수로 간주될 것이다. 그 실수는 워싱턴주에 있던 한 이름없는 소프트웨어 회사(MS)와 비독점적인 협약에 서명하기로 한 IBM의 실수에 버금간다.

익명 사용자의 이미지

이글을 읽고 이제부터 자바광신도들은 죽어지내길 바랍니다.

익명 사용자의 이미지

자바, 닷넷 애덜 싸우는거 보면..

while(1) ;

이거군..

익명 사용자의 이미지

맞습니다. 아는게 없으면 자신이 부족한 지식을 보충하고 나와 다른 견해에 대해 경청할 줄 아는 겸허함으로 토론에 참가하여야 하는데, 저 국케의원들처럼 논지에 맞지않고 감정만 상하게 하는 글들을 올리는 저의가 궁금합니다.
혹시 모노도 아니고 자바도 아니고 리눅스도 아닌 반리눅스 선동의원 데브x아 골수분자?

익명 사용자의 이미지

잘못 올렸습니다. 죄송합니다.

PS. 전 이제 갓 프로그래머 직종에 종사하게 되었고 묘종의 사연으로 윈도우 프로그래밍을 하게 되었지만, 리눅스의 숭고한 자유주의를 찬양하고 M$의 썩어빠진 비양심적인 극악의 상업주의와 그 어떤 정책에도 오직 독점과 폭리의 씨앗이 숨어있음을 경멸합니다.

여기 글들 다 읽어 보았습니다. 아직 무슨 얘기인지 잘 모르는 부분도 있고 여전히 쓰레기 같은 글들 올리는 인간들도 많음을 알겠습니다.
좋은 내용을 올리신 분들도 많았으나 다소 인신공격형 어투로 인해 시비를 걸고 이를 통해 본제와 다른 길로 빠지는 경우도 여전히 많은것 같더군요.
토론의 성격상 자기 주장을 강하게 밀어붙여 상대방을 자신의 의견에 굴복시켜 승부욕을 맛보게 하는 면이 없지 않나 싶은데...
제발 여기 오시는 젊으신 분들이나 나름대로 진보된 인력으로서 저기 쓰레기 같은 국케의원 노땅들처럼 상대방의 감정을 상하게 하거나 의미없는 반론과 정확치 않은 정보를 오보하거나 인용하는 일들은 자제했으면 좋겠습니다.
아직 토론에 깊게 참여할 정도의 능력이 없어 어떤 주장을 내세운 적은 없지만, 적어도 기술적 능력의 우위를 떠나서 프로그래머 대 프로그래머로서 상대방에 대한 존경과 이해를 품고 토론에 임한다면 참으로 건전한 토론이 이루어질 것 같습니다.

익명 사용자의 이미지

프레임워크에 대한 논의는 좀 이상하네요.
저는 언어에 입각한 상식선에서 다음과 같이 생각해 봅니다.(초보자이고 윈도우 프로그램 경험없음) 객체언어가 입력값의 형태와 그에따른 결과만이 있고 내부를 신경쓰지 않는다면 어떤 윈도우폼을 보고 같은 모양과 기능을 다른 사람이 다른 방법으로 구현하는 것이 가능하다고 생각됩니다. 그렇다면 MS의 닷넷프레임을 모노프로젝트에서 MS의 코드없이 동일하게 구현가능할 것이고 실제 그걸 장담했다고 들었습니다. 단 한줄도 새롭게 작성하겠다고! 그렇다면 아래의 논의는 쓸데없는 것 아닙니까? 뭐가 문제이길래 동떨어진 내용으로 다투시는지 모르겠습니다.

익명 사용자의 이미지

논점들은 아래 글들을 보시면 잘 나와있습니다. 위의 본문에서는 마치 닷넷만 리눅스에서 구현하면 윈도우즈와 호환성 측면에서 모든 문제가 해결될 것 처럼 쓰고 있지만, MS가 주도하는 닷넷 프레임워크에 묶였을 때 아래 이야기 한 것 같은 딜레마에 빠진다는게 제 주장입니다. 모노가 MS의 코드를 필요로 한다던지 하는 내용은 아닙니다. 그리고 사실 다툴 이유는 없지요 :)

말씀하신 부분은 물론 이론적으로 가능합니다. 비슷한 개념인 JVM의 오픈소스 구현을 위한 프로젝트들이 진도를 못내는 것을 보면 쉬운일은 아니지만 모노에 참여하는 개발자의 규모 등을 볼 때 가능하다고 생각합니다. 하지만 그 다음이 문제 아닐까요?

제가 볼 때 현재 MS의 닷넷은 'marketing hype'에 가깝습니다. 논의는 무성하지만 실체가 없고, 최소한 제품 출시 이후 1-2년 정도 시간이 지나야 시장에서 검증받을 수 있습니다. J2EE도 그렇지만 닷넷 프레임워크 자체도 전에 없었던 새로운 개념이 아니고 어차피 바닥부터 다시 구현하는 것이라면, 단순히 윈도우즈와의 호환성을 위해 MS의 마케팅의 산물에 성급히 뛰어든게 아쉽습니다.

우려되는 건 일각에서 언급되는 대로 차기 그놈이나 리눅스의 개발 프레임워크가 닷넷기반으로 바뀔 경우 과연 MS의 영향력에서 자유로울 수 있는지 여부입니다.

여러번 예를 들었지만 넷스케이프가 익스플로러의 코드를 사용해서 인터넷환경이 MS에 종속적으로 되는게 아닙니다. 또 HTML이나 CSS의 표준이 없어서 그런 것도 아니고 IE가 표준을 안지키는 것도 아닙니다. 단지 시장에 독점적인 권한을 가진 MS의 '포용해서 확장하는' 정책의 산물일 뿐입니다.

서버측이든 클라이언트측이든 간에 MS의 개발툴, 프레임워크, 방법론, 플랫폼, 제품 등등이 다수에 의해 사용되고 표준화 된다면 그 분야는 더이상 MS의 통제에서 벗어날 수 없습니다.

익명 사용자의 이미지

사실 프래임워크 부분이 그렇케 크게 문제시 되지 않을꺼라 생각합미다..
모노 를 만드는 곳이나 그놈을 만드는 곳이나.. 다 똑 같은데이니까요..

그놈의 형태가 오히려 MS에 종속적이 된다는 말에 일리가 있긴 하지만
프레임 워크가 종속된다 한들.. 리눅스와 윈도우의 호환성만 된다면..
QT나 GTK로 프로그램을 짜는것보다는 모노를 이용하는게 더 매력적인게
될것입미다
그런게 걱정이지.. 프래임워크는 문제가 될수 없습미다.. 윈도우용 김프와는
달리 생각을 해야한다구 생각합미다..
오히려 닷넷 프로그래머가 많아진다는게 과연 좋은 일인가 ... 라는 것 말입미다
저같아도 모노는 GTK의 연속이라는 측면이라 생각하고 윈도우와의 호환성을 생각
한다면.. 닷넷으로 프로그램을 짜고 싶을 겁미다.. 일거양득..이라구 하죠..

그리고 사실 윈도우때문에 리눅스가 망하진 않을꺼라 확신합미다.. 그리고 모노가
윈도우와 호환이 되지 않는다면.. 그 또한 별로 매력적이지 못한거라 생각합미다..

익명 사용자의 이미지

논외의 얘기지만
.NET은 무시하고 Mono끼리만 호환이 된다해도 그리 나쁘진 않다고 봅니다.
리눅스라는 범위에 국한해서 생각해 보면 별로 매력이 없는 것이 사실이나
FreeBSD, OpenBSD, NetBSD, HURD, Solaris, Minix등등등
Windows제외한 즉 모든 비MS계열 OS가 Mono로 호환이 된다면
충분히 매력적이리라 봅니다.
자바로 이짓하면 아마 SUN에서 소송 들어 올겁니다.

물론 그런 바탕위에서 MS.NET까지 호환해주면 너무도 매력적이겠지요.
그러면 리눅스와 Windows간 뿐만 아니라
거의 모든 운영체제간에 호환이 이뤄집니다.
Mono덕분이지요.
MS에게 거의 모든 운영체제에 맞게 그거 만들어 달라고 하는건 현실적으로 불가능할뿐아니라
바라는것 자체가 코메디에 가깝습니다. ^^

MS.NET응용프로그램이 Mono에서 돌아가지 않아서 MS.NET과 Mono간의 호환이 안된다고 해도
Mono의 프레임워크를 가져다가(한쪽방향이 안된다고 반대쪽 방향도 안되는건 아니지요)
Windows의 Visual Studio.NET으로 개발하는 것은 충분히 가능하리라 봅니다.
물론 만든 프로그램이 Windows에서는 최적화로 안돌아갈지 모르지만 사용은 Mono에서 할테고 ^^

다른 말로 하자면, 윈도우 개발자들이 리눅스를 위해 프로그램을 작성하는 것이 쉽다면 그들은 리눅스를 위한 프로그래밍을 할 것이다. "전혀 다른 API"!!!!!를 재교육 받는 것조차 개발자들은 개의치 않을 것이다.

익명 사용자의 이미지

사실 MS의 방향에 좌우되지만 않는다면 닷넷 프레임워크 자체는 꽤나 매력적이라고 생각합니다. 하지만 제 생각에도 바이너리 호환은 현실성이 없을 것 같고 리눅스나 그놈을 개발하는데 있어서 일관된 인터페이스를 제공하는데 주력한다면 나쁘지 않습니다.

단 개인적인 감정이지만 리눅스 개발자들이 VS.NET으로 개발하는 건 보고싶지 않군요. 제가 속이 좁은가요 :)

익명 사용자의 이미지

사실 완전한 바이너리 호환은 이상일뿐이며 현실적이지는 못합니다.

썬에서도 소송걸 이유도 바이너리 호환이 깨지거나 프레임웍의 난립때문이라고 생각합니다.

반면 MS에서는 위와 같은것을 알고 대신 다중언어를 강조한것이죠.

위의 말씀대로 MS.NET Framework 은 MS에서 구현한것일뿐이며,
단지 mono가 MS.NET Framework 과 호환성을 맞춰나가는 형태입니다.

사실 어느 플랫폼에서 컴파일한것을 다른 플랫폼에서 돌리는 것보다는
프로젝트를 그대로 가져와서 재컴파일 하는것이 더 유리하지 않을까하는 생각입니다. 물론 소스의 수정 없이 된다면 가장 좋을것입니다.

익명 사용자의 이미지

다시보는 모습인데요.
단지 추측 그리고 부정적 묘사
아무리해도 이 병은 고쳐지지 않나 봅니다.

익명 사용자의 이미지

과거 행적에 근거한 예측, 비판적 고찰
항상 이러도록 노력해야죠.

익명 사용자의 이미지

계속 지켜봤는데... 당신 참 예의가 없군요.
읽는 사람 짜증납니다.

익명 사용자의 이미지

앞에서 한 소리 들으셨다고 똑같은 말로 보복하려 하시다니, 상당히 유아적인 행태입니다.

익명 사용자의 이미지

맞습니다. 아는게 없으면 자신이 부족한 지식을 보충하고 나와 다른 견해에 대해 경청할 줄 아는 겸허함으로 토론에 참가하여야 하는데, 저 국케의원들처럼 논지에 맞지않고 감정만 상하게 하는 글들을 올리는 저의가 궁금합니다.
혹시 모노도 아니고 자바도 아니고 리눅스도 아닌 반리눅스 선동의원 데브x아 골수분자?

익명 사용자의 이미지

.

bxhs의 이미지

윈상에서 닷넷은 자바로는 불가능(?)했던,
거의 MFC로 만든 GUI와 맞먹는 속도를 내게
될것입니다.

클라이언트 서버 모두 윈도우에서는
좋은 성능을 보이겠죠.

따라서..윈도우에서는 닷넷이
자바를 대체할거라고 생각합니다.

하지만 리눅스에서는???
리눅스에서 닷넷은 거의 자바와 비슷하게
될거같습니다.
표준화되고 잘 정의된 UI인터페이스가
부재하기때문이죠.

자바애플릿이나 자바 GUI 응용프로그램의 경우
리눅스에서 거의 최악의 수준이였다고
기억합니다.
(1.2.1까지 다루다가 그만둬서..
지금은 잘 모르겠읍니다만..)

따라서 그냥 서버계열로 쓰이겠죠.

그래서 결국,
윈도우에서 닷넷 클라이언트,
리눅스에서 닷넷 서버로 쓰인다면...
결국엔 자바만 왕따 당하는걸로
모든게 마무리 지어질지도 ....
모르겠군요..
어차피 같은걸 써야 통신하기도 편하고,
그럴테니..

단순한 추측이였읍니다.^^

익명 사용자의 이미지

개인적으론... Mono에 굉장히 지지를 보냅니다.

M$에 끌려갈 가망성이 크다... 머.. 그런 이야

기도 있지만... 또 어느정도 공감하지만...

전 오히려 리눅스에 도움을 주면 주었지 해를끼

치리나는 생각은 안합니다. 얼마전 M$관계자가

울 회사에서 말하기를... --; 이제 유저들이

서서히 OS에 대해 신경을 안쓴다고 합니다...

유저들이 필요로 하는 것은 오직 브라우져 뿐..

이라구... --; M$가 위기를 느끼는 것은 그런

부분이구.. 더이상 OS만으로는 매리트가 없다

고 느끼는 거구.. 그래서 XBox니 .NET이니 하

는 것을 내놓은다구... 리눅스에 닷넷이 올라가

는 것은 좋은일이지 절대로 나쁜일은 아니라고

봅니다.. JVM이 Linux용으로 포팅 되었을때도

이렇게 논쟁이 심했는지? --; 궁금하네요...

별 달라 보이지도 않는데...

익명 사용자의 이미지

프레임워크(라이브러리)를 계속 문제시 하기 때문에 그 관점에 관해서 비유적으로 얘기해 보죠.

a라는 실행파일은 b라는 라이브러리를 사용하는 파일이고 b라는 라이브러리가 시스템상에 없을때

a를 실행했을때 "B라는 라이브러리가 없습니다."
라고 나오겠지요.
그러면 혹자는 이렇게 반응할 것입니다.
그 실행파일 형식은 b라는 라이브러리를 필요로 하고
b라는 라이브러리는 MS에서 만드는 것이므로
그런 실행파일 형식 쓰지말자. -_-;;;

d라는 실행파일이 e라는 동적라이브러리를 사용하고 e라는 라이브러리는 시스템상에 존재합니다.
d를 실행하면 아주 잘 실행됩니다.
그러면 혹자는 이렇게 반응할 것입니다.
MS에서 b라는 라이브러리의 형식을 바꿨다.
그런 실행파일 형식 쓰지말자. -_-;;;

익명 사용자의 이미지

우선 프레임워크에 대한 정확한 이해가 필요합니다. 프레임워크는 단순히 프로그램 언어에서 불러서 사용하는 라이브러리가 아닙니다. 개발 전체에 영향을 주는 하나의 패러다임이라고 보시면 됩니다.

님이 C나 C++프로그래머라면 만일 누군가 앞으로 리눅스 프로그램을 하려면 자바로 짜야된다고 하면, 아니면 강제는 안하더라도 다른 모든 환경이 자바를 우선적으로 지원한다면 리눅스 프로그램을 계속 짜시겠습니까?

제가볼 때 오히려 언어가 단일화되는 것보다 프레임워크가 단일화되는게 더 큰 제약이 됩니다.

더구나 더 큰 문제는 그러한 프레임워크의 방향은 MS에 의해 좌우될 확률이 크다는 것입니다.

익명 사용자의 이미지

오히려 자바 개발자가 가지는 프레임워크에 대한 인상이 이상하다고 느껴지는군요.
자바로 짜라 그러면 그렇게 될 수도 있겠지요.

가장 널리 쓰는것만 두개 고르자면...
C++에서 프레임워크는 QT나 MFC가 대표적일 것입니다.
MFC가 나쁘다고 C++이 나쁘고 그래서 QT로도 짜지마란 얘깁니까?

프레임워크가 단일화가 되다니요.
C++의 경우 문법과 기본적인 라이브러리정도만을 표준화하고 있기 때문에
MFC든 QT든 또 다른 뭐든 쓰면 됩니다.
실지로도 쓰고 있고
.NET쪽도 C++처럼 프레임워크쪽에는 아무런 표준화가 없습니다.
표준화 된건 문법과 실행환경정도...

그러니 MFC랑 QT가 별개이듯이
환경만 구축되면 프레임워크는 충분히 별개로도(위의 비유에서 QT) 존재할 수도 있고
제일 먼저 나온 프레임워크까지(위의 비유에서 MFC) 지원해 주면 금상첨화라 할 수 있을 것입니다.

프레임워크 단일화라고 무언가 착각하시는듯 계속 말씀하시는 것은
아직까지 .NET Framework밖에 없기 때문일 것입니다.

Framework도 여러개 있을 수 있고
Language도 여러개 있을 수 있겠지요.

익명 사용자의 이미지

>>"C++에서 프레임워크는 QT나 MFC가 대표적일 것입니다"

라이브러리, 그래픽 툴킷, 그리고 어플리케이션 프레임워크에 대한 이해가 부족하신 것 같습니다.

사실 그래픽 툴킷만 가지고 이야기해도 윈도우즈에서 MFC 기반의 네이티브 인터페이스를 갖는 어플리케이션이 GTK나 스윙으로 기반 어플리케이션에 비해 가지는 어드빈티지를 이야기할 수 있습니다만 프레임워크는 그것 보다도 큰 개념입니다.

님께서는 언어와 플랫폼, 그리고 라이브러리와 프레임워크 등의 개념을 명확히 구분하셔야 좀 더 생산적인 토론을 할 수 있을 것 같습니다.

익명 사용자의 이미지

익명 사용자의 이미지

솔직히 닷넷에 대해 얼마나 이해하고 계신지는 모르겠습니다만, 닷넷을 그래픽 툴킷과 같은 레벨에서 이야기하는 건 말꼬리잡기로 밖에 안보이는 군요.

그리고 그래픽 툴킷의 도입도 생각하는 것만큼 그렇게 단순한 문제는 아닙니다. 만일 지금의 그놈을 GTK기반에서 QT로 바꾼다면 어떻게 됩니까? 어차피 둘 다 그래픽 툴킷이니까 그냥 바꾸면 그만입니까?

아무리 언어가 같아도 Win32플랫폼이나 그놈 환경이라는 플레임워크의 차이는 그 만큼 넓습니다. Win32나 그놈을 전제로 하면 그 위에서 일어나는 개발은 MS나 그놈 개발자들이 정하는 방향에 따를 수밖에 없습니다.

익명 사용자의 이미지

MFC와 QT를 단순하다!!라고 단정하는 생각도 이상하군요.
MFC에는 GDI관련 class들만 있는 것이 아니고...
QT에도 그래픽 위젯들만 모여 있는 것 또한 아니죠.

MFC와 QT는 님이 얘기하시는 Framework와 달리 단순하다고 지적하고 싶은 것으로
개발방식을 얘기하고 싶은신가 본데 말이죠
예를 들어 QT의 SLOT, SIGNAL 방식이 (MFC에 없는 것?을 예로 들어봤습니다.)
Java의 기능에 비하면 엄청 단순해서 개발방식이라고 얘기해 주기도 뭐한가 봅니다. -_-;;;
그렇다고 SLOT, SIGNAL 방식이
C++의 기본적인 개발방식(C++이라면 당연히 그렇게 해야한다.)이라면 왜 MFC에는 없죠?
당연히 기본적으로 지원해 주는 것이 아니고 MFC와는 별개의 것이기 때문이죠.

말꼬리 잡으려는 사람은 오히려 님이라고 보아지군요.
제가 .NET Framework 얘기하다가 C++에서의 MFC와 QT를 예로 든 이유가 무엇입니까?
.NET Framework와 그것이 같은 레벨이라서 그랬던 것입니까? -_-;;;
같은 기반(C++)에서 별개의 것(MFC, QT)이 존재할 수 있다는 예 아닐까요?
소위 말하는 난독증은 아닐지...

MS에서 MFC를 바꾸던 말던 C++(기반자체)만 안바꾸면 QT는 아무 문제 없습니다.
마찬가지로 .NET Framework를 바꾸던 말던 CLI나 C#등을(기반자체) 안바꾸면 문제가 없는데
여기서 중요한 건 이미 이걸(기반자체) ECMA에서 관리하고 있죠.

뭐 혹시 ActiveX나 COM같은 것을 얘기하고 싶은 것입니까? (컴포넌트 "개발모델"!!)
다른 거 선택해서 쓰면 되겠죠.
include나 import기능이 MS의해서 원천봉쇄라도 당했나봅니다.
다른 컴포넌트 모델을 쓰면 되지 않습니까.
C++에서는 MS에서 만든 ActiveX나 COM말고는 컴포넌트 모델이 불가능한가 보죠?
안 그렇잖아요. 컴포넌트 모델까지도 별개로 충분히 존재할 수 있단 얘깁니다.

자바에서는 SUN쪽에서 컴포넌트 모델 어떻게 만들면 그거 쭈욱 따라가고 그러는지 모르겠으나
저쪽 동네(C++)는 안따라가도 됩니다.
심지어 Borland는 C++기반에 Windows기반임에도
독자적인 컴포넌트 모델을 가지고 있는 것으로 알고 있습니다.
너무 자바적인 사고방식으로 접근하지는 말아주시길... 자바가 아니니

익명 사용자의 이미지

저는 오히려 님께 너무 언어 자체에 시각을 국한시키지 말라고 말씀드리고 싶습니다. 물론 분야에 따라 언어 자체의 구사능력이 무엇보다 중요한 경우도 있습니다만 닷넷이나 J2EE가 주 타겟으로 삼는 시장에선 그렇지 않은 경우가 더 많습니다. 닷넷에서 C#은 아주 작은 일부분에 불과합니다. 닷넷의 기반을 C#으로 이해하고 계시다면 조금 더 공부를 해보시기를 권합니다.

C++만 알면 무슨 플랫폼에서 무슨 개발을 하던 다 통한다고 생각하는 건 너무 나이브 하지 않나요? Win32에서 ActiveX나 Com+이 싫으면 안쓰면 그만이라고 하시는데 솔직히 Win32에서 어느 정도 심각한 수준의 프로그래밍 경험이 있으신지 궁금하군요.

C/C++의 소스레벨 호환성도 훌륭하기는 하지만 프레임워크나 패턴 단위로 돌아가는 세상도 있다는 걸 무시하지는 마시기 바랍니다.

익명 사용자의 이미지

언어자체에 국한해서 생각한적 없습니다. 그런 부분은 일일이 자세히 대응 안하겠습니다.
예들은 모조리 "같은 기반에서 다른 것이 별개로 존재할 수 있다."는 말이 성립함을
보여주는 예이지 않습니까.

(자바에서는 SUN에서 얘기하는 하나만 있어야 되는지 모르겠지만...)
Windows기반이라 할지라도 MS의 컴포넌트 모델, Borland의 컴포넌트 모델이 존재할 수 있고
C++기반이라 할지라도 그 Framework는 구현하기에 따라 별개로 존재할 수 있다는 예 아닙니까.

님의 얘기는 동문서답이라고 생각됩니다.
Borland의 컴포넌트 모델이 있다고 하는데
"너무 나이브 하지 않나요?"라던가 실력을 의심하는 등의 소리는
요점을 전혀 파악하지 못한 반응이라고 밖에 생각되지 않는군요.

님의 주장이 성립할려면 실지로 Windows에는 컴포넌트 모델이 MS꺼만 있어야 되는거 아닙니까?
Windows에서 사용할 Class Library는 MFC흉내내기에 급급해야 하고 말이죠.
프레임워크라는 단어를 신성시 하는 듯하여 용어 바꿔드리기는 했으나
일반적인 의미는 http://terms.co.kr/framework.htm 중에 1번입니다.

이런 것이 님의 글쓰기 특기로 보이기도 합니다만 "동문서답"이라는 평을 받지 않으려면
다음 질문의 입장만 분명히 하면 될듯 싶군요.
"같은 기반에서 다른 것이 별개로 존재할 수 있다."는 말을 인정합니까? 못합니까?

그런 예를 자꾸 들었던 것은
최악의 경우!! MS가 .NET Framework를 초기의 형태와 심하게 다르게 변형한다 하더라도
CLI나 CLR같은 기반은 표준화가 되었기 때문에
.NET Framework가 어찌되던 상관없이
오픈소스 커뮤니티는 그걸 기반으로 독자적인 활용까지도 가능하다는 뜻입니다.

님의 논조로 봐서 자바로 그걸 이루기에는 불가능에 가깝겠군요.

익명 사용자의 이미지

그놈과 같은 오픈소스 프레임워크가 닷넷 기반으로 옮겨가는 것의 의미를 파악하기 위해선 닷넷이나 이와 유사한 J2EE등의 어플리케이션 프레임워크에 대한 이해가 필요합니다. 님이 계속 그래픽 툴킷이나 라이브러리에 비유를 하며 제가 말하는 프레임워크와 전혀 별개의 개념을 똑같은 것이라고 주장하니 제가 어떻게 하겠습니까? 같이 닷넷 스터디라도 해야 합니까? 이런 문제는 시각차로 남겨 두고 이 글을 읽는 다른 분들의 판단에 맡기는게 나을 것 같습니다.

>>"같은 기반에서 다른 것이 별개로 존재할 수 있다."는 말을 인정합니까? 못합니까?

실제로 닷넷이나 J2EE등의 프레임워크에 대해 지식이 없으면서 논쟁에는 이기려 하기 때문에 이런 원론적인 문제로 말꼬리를 잡는게 아닌가요?

굳이 답변을 드리자면 네 그렇습니다. 존재할 수 있습니다. 그런데 어쨌다는 겁니까? C/C++로 갈레온도 짜고 MS오피스도 만들고 GTK도 만들고 QT도 만듭니다. 그래서 리눅스에서 MS오피스 돌아가고 윈도우즈에서 그놈 띄우나요?

님이 만약 상업적으로 Win32를 타겟으로 클라이언트 프로그램을 짜는데 GTK인터페이스에 GNU C++써서 하시겠습니까? 프로그램에서 익스플로러 임베드하고 오피스 문서 연동해야하는 상황이면 어떻게 할 겁니까?

그놈에서의 개발은 그놈 개발자들이 정한대로가고 Win32에서 개발은 MS가 정한 방향으로 갑니다. 아무리 개발자가 잘나고 C/C++이 소스 레벨 호환이 되도 실제 상업적 목적으로 프로그램을 짜는데 굳이 프레임워크 쪽의 지원을 마다하고 처음부터 맨땅에 헤딩해서 만드는 건 만용입니다.

닷넷의 변형 가능성에 대한 부분은 누차 플랫폼 확장 기능에대한 딜레마에 대한 문제를 지적하는 것으로 할 이야기를 다했습니다. 제발 남을 비판하려면 글부터 제대로 읽고 하시기 바랍니다.

>>님의 논조로 봐서 자바로 그걸 이루기에는 불가능에 가깝겠군요.
또 자바 이야기가 왜 나옵니까?

딴지를 위한 딴지나 논쟁에 이기기위한 논쟁은 지양했으면 좋겠습니다.

익명 사용자의 이미지

그러면 Mono는 미구엘이 정하는 바대로 가겠군요.
MS가 정하는건 별개이고...
그렇죠?

익명 사용자의 이미지

맞습니다. 하지만 제발 아래 논의를 다시 읽어보시고 제 주장이 무엇인지를 먼저 파악해 주셨으면 합니다. 왜 모노가 본문에서와 같은 윈도우즈 호환을 목표로 한다면 MS에 따라갈 수밖에 없는지는 충분히 말씀 드린 것 같군요,

익명 사용자의 이미지

(특정인을 지목하기는 뭐하지만) 조기태님 글에는 객관성보단 개인적인 감정위주라고 생각됩니다.

우선 프레임워크 부분을 보면

1.모노에 프레임워크의 선택권이 생긴다면
(모노에서 GTK를 사용하는 것처럼 라이브러리를 새로 개발 C#과 CLI등을 활용할 수 있다.)

조기태님 얘기하기를 그러면 MS의 프로그램들이 안돌아 간다.

2.모노에 프레임워크의 선택권이 생기지 않는다면
(모노는 단지 .NET의 프레임워크를 충실히 따라가려 노력한다.)

조기태님 얘기하기를 그러면 MS의 정책에 놀아난다.

이래도 싫고 저래도 싫은 사람과 과연 토론이 될런지 의문입니다.
제가 무언가 잘못 느끼고 있다면
입장을 분명히 밝혀 주시기 바랍니다.

익명 사용자의 이미지

저의 의견을 요약하신 부분은 크게 문제가 없는 것 같군요. 물론 구체적인 내용은 한 줄짜리 요약 보다는 아래 다른 글을 보셨으면 합니다.

제가 지적한 건 바로 위와 같은 딜레마지만, 그런 딜레마가 발생한 이유는 바로 오픈소스 진영에서 MS의 핵심 제품을 가져다가 중요 개발 프레임워크로 사용하려 하는데서 온다고 생각합니다. 그래서 어느 쪽을 선택해도 만족스럽지 못한 결과가 발생할 것을 우려하는 것입니다.

님께서는 MS의 프레임워크를 포팅하는 당위성은 전제하고, 토론 내용이 어떻게든 모노에 좋은 방향을 찾는 것으로 생각하고 계신 듯 합니다.

요약하면 저는 처음부터 MS의 닷넷을 포팅한 것 자체가 잘못이라고 생각합니다. 오해 없으셨으면 좋겠군요.

익명 사용자의 이미지

그렇다면 Java던 .NET이던 그걸로 Application을 만들겠다는 생각 자체를 부정하는 것입니까?

익명 사용자의 이미지

당연히 아니지요... 제가 J2EE로 밥먹고사는데요 ㅡ.ㅡ;;

이제까지 닷넷이나 자바 없이 그놈이나 리눅스 어플리케이션을 잘 만들어 써오지 않았습니까? 만일 기술적인 이유로 새로운 프레임워크가 필요하다면, 왜 하필 리눅스에서 MS의 주력 제품을 클론해야하는지 의문일 뿐입니다.

Wine같은 경우도 Win32 API의 클론이지만 앞으로 그놈이나 리눅스의 개발 방향을 획일화할 위험이 없다는 점에서 모노와는 다릅니다.

익명 사용자의 이미지

저는 이렇게 생각합니다.

그놈(미구엘)쪽에서 mono를 만들었죠. 리눅스에서 닷넷을 구현했다고 보고,

그런데 MS.NET에서 만든것이 mono에서 돌아갈런지는 모르겠습니다만 돌아간다해도 어느정도 수정이 필요하다고 봅니다. 중요한것은 CLS를 준수하는 겁니다.

단지 문제가 .NET을 MS가 처음구현했다는 것일뿐입니다. 베타시절에 CLR, CLS를 ECMA에 제출했으며 ASP.NET, ADO.NET 이런것은 MS가 처음구현을 해서 그렇습니다. 라이브러리나 프레임웍이라고 보면 됩니다. 당연히 뒤늦게 개발하는 mono가 ASP.NET, ADO.NET 을 구현할수 밖에 없습니다. .NET은 워낙 광범위해서 플랫폼 중립적인것 이외에 COM,Win32 도 포함(?)하거나 사용할수도 있는 것입니다. 이것은 MS가 처음 구현해서 그런것입니다. mono라면 리눅스에 종속적인요소는 다른식으로라도 구현을 할것이라보고 MS.NET과 호환성을 유지할것이라봅니다.

아마 mono는 .NET에서 플랫폼 중립적인 특징을 구현하면서 MS.NET과의 호환성을 맞춰가는데 의미를 둘것 같습니다. 어플리케이션이 그대로 돌아가는 것보다는 포팅을 쉽게할수 있는것이 더욱 의미가 크다고 봅니다. 어차피 다른 시스템이고 시스템 종속적인것이 있으니 말입니다.

즉 클론이라고 볼수는 없습니다. MS.NET mono.NET 처럼 구현 제품이라고 보면 되겠습니다.

MS.NET, mono.NET의 공통점과 차이점의 범위가 모호한것이 문제군요.

// 갑자기 써서 두서가 없었군요...

익명 사용자의 이미지

>>MS.NET, mono.NET의 공통점과 차이점의 범위가 모호한것이 문제군요.

맞는 말씀입니다. 이 부분이 핵심이라고 생각합니다. 제가 클론이란 표현을 써서 논지가 불명확해졌는지 모르겠습니다. 어쨌든 중요한 건, 말씀대로 분명 MS.NET이나 Mono.NET 모두 플랫폼 종속적인 확장요소들을 가지고 있다는 점입니다.

이 부분을 무시한다면 플랫폼 호환의 의미가 퇴색하고 그렇지 않다면 MS.NET의 방향대로 따라가야하는 딜레마에 빠지는 것이 문제라고 봅니다.

따라서 어차피 MS가 만든 코드를 사용하는 것도 아니고 처음부터 새로 구현을 하는 것이라면 리눅스를 중심으로 한 오픈 플랫폼에서 개발 생산성을 최적화할 수 있는 프레임워크를 새로 디자인하는게 낫지 않나 싶습니다. 어차피 VM기반이라면 바이너리 호환도 가능하겠지요.

그럼...

익명 사용자의 이미지

그런데 새롭게 설계할 능력이 된다면 이미 하지 않았을까라는 생각이듭니다. 설계는 ECMA에 제출한것으로 하면 될것이고 구현은 지금 하고 있는데 .NET 프레임웍도 이미 MS가 먼저 설계를 하였으므로 MONO는 따라가고 있는것입니다. 호환성을 위해서 그렇게 한다고 보면 별도의 리눅스에 맞는 프레임웍을 추가해보는 것은 어떨까 싶습니다. MS에서 먼저 만드는 것 보다 먼저 MONO에서 다른 프레임웍을 만드는 것도 좋을것 같습니다. 하지만 mono가 잘될려면 이미 만들어진것을 확실히 수용하는것이 먼저입니다. 기존의 것과 다르게 만드는것은 기존의 GNOME 밖에 안된다고 봅니다.

바이너리상의 호환은 분명 재컴파일없이 실행된다는 뜻인데 명세만 맞추면 될것이며 플랫폼 종속적인것은 래핑이나 다른 방법으로 해결해야 할겁니다. 분명 CLR,CLS 등을 ECMA에 제출한것만으로도 .NET은 충분한 가치가 있습니다.

그리고 개념은 VM 이지만 JAVA와는 다른면도 있습니다. 처음설계될때 .NET(CLR)은 다중언어를 염두해뒀습니다. 플랫폼측면은 자바와는 반대로 구현하기 나름대로입니다. .NET 개념이 플랫폼중립보다는 다중언어에 더 큰비중을 두었기 때문입니다. 단지 구현을 얼마나 잘하느냐에 달린거죠. 분명 완전한 바이너리의 호환은 없을것입니다.

앞으로 1. MONO가 얼마나 MS.NET을 잘 구현하느냐
2. 구현잘했으면 리눅스에 맞는 프레임웍을 설계할것인가?

이라고 봅니다.

모노와는 다르게 FreeBSD에는 완전한 포팅이 이루어졌다고 하므로 FreeBSD의 프레임웍의 변화를 봐야겠죠.

하여간 자바와 닷넷의 나아가는 방향이 다르기 때문에 비유하기에는 부족하군요.

익명 사용자의 이미지

다른 부분에는 거의 공감합니다. 다만 ECMA에 제출된 스펙으로 호환성 있는 닷넷을 구현할 수 있다는데는 조금 회의적입니다.

MONO가 얼마나 MS.NET을 잘 구현하느냐가 문제라고 하셨는데 제가 가장 크게 문제삼는 부분이 처음부터 왜 모노가 MS.NET을 따라가야 하는지 하는 점입니다.

KDE가 윈도우즈 비슷한 모양을 따라가는 것 조차도 민감하게 반응하는 사람들이 많은데, 아예 개발 플랫폼을 따라간다는 말에는 눈에 보이지 않아서인지 크게 반발이 없는 것 같아 이상합니다.

익명 사용자의 이미지

정작 핵심적인 부분을 빼먹었군요. 님께서는 MS가 먼저 시작했기 때문에 모노가 따라가는 것이라고 하셨지만, 그랬을 경우 리눅스의 발전 방향은 MS의 조정을 받게되는게 아닌가요?

아무리 HTML/CSS 표준이 잘 정의되어 있어도 90%이상의 사용자가 익스플로러를 쓰기때문에 실제 인터넷 환경은 브라우저 종속적으로 변해버렸습니다.

닷넷의 경우 98%의 점유율을 가진 윈도우즈 클라이언트 시장과 점차 세를 늘여가는 윈도우즈 서버 시장에 대한 MS의 영향력을 고려하면 앞으로의 발전 방향이 누구의 손에서 정해질지는 쉽게 보이는 것이 아닐까요?

익명 사용자의 이미지

그럼 SUN이 자바를 만들고 MS가 닷넷을 만드는것도 MS가 SUN의 조정을 받게 되는건가요? :)
조정할려고 해도 안따라올수도 있고, 조정안해도 잘따라갈수도 있는것입니다.

제생각에 아마 따라가는 이유는 어느정도 MS.NET에서 만들어진 소스코드를 돌릴수 있기 위한것이라고 봅니다. 사실 바이너리 호환은 바라지도 않습니다.

익명 사용자의 이미지

C#과 CLI는 ECMA에서 관리합니다.

익명 사용자의 이미지

C# + CLI < .NET 이니까 문제지요 :)

익명 사용자의 이미지

MS의 영향을 받는 것은 .NET Framework이지 C#과 CLI가 아닙니다.

익명 사용자의 이미지

C#에 대해선 전혀 반대할 생각도 없습니다. 리눅스에서 사용할 수 있는 언어가 하나 늘어난다면 좋지요.

C#-GTK 바인딩 같은 걸로 그놈 어플리케이션을 개발하면 좋겠지요.

익명 사용자의 이미지

바인딩이 아니라 CLI상에서 돌아가게 한다면
바이너리 호환성까지 가질 수 있을텐데요.

익명 사용자의 이미지

정확하게 이야기하면 CLR에서 돌아가게 한다면 그렇겠지요. 하지만 바인딩이 아닌 CLR이 도입된다면 그건 단순히 언어지원이 추가되는게 그치지 않습니다.

예를들어 그놈 환경이라면 그놈 어플리케이션을 제작하는 방법자체가 완전히 바뀌는 결과를 가져옵니다. C#/CLR만 가지고 이야기 한다면 상대적으로 MS의 영향을 덜받겠지요. 하지만 닷넷과 CLR을 분리해서 적용할 수 있는지, 또 그런 접근법이 올바른 것인지에 대해서 확신이 없군요.

익명 사용자의 이미지

정답이네요. .NET Framework은 C#으로 구현했다라고 해석하면 될까요?

익명 사용자의 이미지

Gnome 프로그램이 Mono기반이라면
FreeBSD용, Linux용, HURD용, Solaris용 기타등등
일일이 컴파일 안해도 되지 않습니까.
그런 매력적인 일을 왜 외면해야 됩니까?

Windows용을 제외하더라도 충분히 매력적입니다.
Windows가 그걸 어떻게 다시 바꾸던지 상관없이
여전히 FreeBSD용, Linux용, HURD용, Solaris용 기타등등
일일이 컴파일 안해도 되지 않습니까.

일일이 컴파일 안해도 된다면
거기서 끝나는 것이 아니라 아마도 패키지 시스템 자체에도 큰 변화가 있을 것입니다.
i386, sparc, ppc 그런거 일일이 안따져도 됩니다.
source가져다 일일이 컴파일안해도 바로 쓸 수 있습니다.

최적화는 Mono의 JIT에서 할테니
일일이 최적화하겠다고 새로 컴파일할 필요도 없겠지요.

그런 상황에서 Windows용까지 아무런 제약없이 돌아가면 금상첨화가 되는 것이겠지요.
Windows용 때문에 위에 나온 것들을 포기합니까?

익명 사용자의 이미지

바이너리 호환성을 위한 가상머신이란 개념이 모노나 닷넷으로 부터 시작된 것도 아닌데 왜 닷넷이 아니면 아무 것도 안된다고 생각하시는지 모르겠군요.

그럼 왜 닷넷은 안되냐고 물으신다면 아래 글들을 읽어보시라고 말씀드려야 될 것 같습니다.

"닷넷을 쓰면 편리한데 왜 반대를 하는가?"하는 주장에 대해서는 이제까지 MS와 관련해 나왔던 이야기들을 꼼꼼히 살펴 보셨으면 좋겠습니다.

익명 사용자의 이미지

MS를 얘기해서 Mono를 반대하는 건 어불성설입니다.

비유적으로 UNIX를 얘기해 보죠.
MS를 AT&T라고 해 봅시다.
AT&T(MS)가 버클리(표준화 기구)에 그거 쓸수 있게 해 줬습니다.
버클리(오픈소스 커뮤니티)에서도 그래서 UNIX를 만들었죠.

AT&T는 근데 BSD랑 다르게 나갑니다.
그렇다 해도 BSD는 AT&T와 별개로 훌륭한 유닉스입니다.

무슨 얘긴지 아시겠습니까?
MS가 뭔짓을 해도 아무런 상관이 없습니다.
MS의 .NET용 프로그램까지 돌리겠다하면 그부분을 추가하면 됩니다.(쉽지는 않겠죠.)

BSD가 다른 유닉스와 호환성을 가지기 위해 기능을 추가하는 것과 마찬가지입니다..

또한 다른 유닉스에서 BSD로 옮겨가는 것은 쉬운 일입니다.

익명 사용자의 이미지

무언가 제가 주장한 내용에 대해 논리적 근거를 들어 반박을 해주셨으면 좋겠습니다. 저는 MS가 모노에 영향력을 행사할 수 있다고 보고 님은 그렇지 않습니다. 서로 그렇다 아니다만 계속 반복해서 말한다면 싸움밖에 더되겠습니까?

저는 이미 아래에서 수차례 "왜" 영향을 받을 수밖에 없는지 말씀드렸습니다. 토론을 하시려면 "왜" 영향을 안받는지를 설명해 주시거나 제 논리의 오류를 지적해주셔야 하지않을까요?

익명 사용자의 이미지

말씀중에 닷넷의 다중 언어지원이 별 도움이 안된다고 하시는데 그건 좀 약간은 비약 것 같습니다.

이 주장을 하신 분께서는 C, C++, Cobol 이런 여러 언어로 동시에 프로젝트를 수행하면 유지보수가 안된다는데 맞는 말씀입니다.

그렇지만 누가 그렇게 프로젝트를 진행 하겠습니까.

그 회사의 개발자가 C++을 잘하면 C++로 만들고

java를 잘하면 java로 만들겠죠. 아마 회사마다 틀릴겁니다. 개발언어의 선택은 회사 개발자의 숙련도, 유지보수의 용이성등 다양한 고려에 따라 프로젝트 진행전 정해질 겁니다.

닷넷의 다중 언어지원은 동일한 기능의 애플리케이션을 언어에 상관없이 만들수 있다는 거라고 알고 있습니다.

그렇다면 그 기능은 회사에게 개발자에게 맞는 언어를 선택 함으로서 유지보수, 개발의 용이성이 증가를 가져오지 않을까 합니다.
(새로운 플랫폼에 대한 적응 비용은 제외 했습니다.)

익명 사용자의 이미지

비약일 수도 있지요 (사실 Cobol로 웹개발 하려는 사람이 있을지 모르겠군요 :)) 하지만 '소수언어의 수호자' 등과 같은 표현에서 보듯이 그 만큼 MS의 마케팅도 비약과 과장(hype라고 하지요)으로 포장되어 있습니다.

플랫폼에 대한 적응 비용보다는 다중언어를 지원함으로써 얻는 이익이 크다고 생각하신다면 VB 6.0과 VB.NET을 비교해보시기 바랍니다. 아마 C#.NET사용자가 J++.NET을 배우는 것보다는 서너 배의 노력과 시간이 필요하지 않나 싶습니다. 개인적으로 닷넷의 다중 언어 지원은 마치 영어를 한글로 발음대로 적어 놓고 한국 사람들에 친화적이라고 말하는 것 같이 느껴집니다.

리눅스의 특성상 다양한 언어가 사용되기 때문에 닷넷의 이러한 점은 매력적으로 받아들여질 수 있지만, 제 생각에는 어디까지나 GTK, QT등에 대한 각 언어의 바인딩을 추가 하는 방향으로 접근하는게 올바른 방향인 것 같습니다. 리눅스의 개발이 모두 닷넷 프레임워크 바탕으로 이루어질 때 MS의 입김에 의해 닷넷의 방향이 좌지우지 된다면 결국 리눅스 전체가 MS의 손에서 조정되는 결과가 되기 때문입니다.

그럼...

익명 사용자의 이미지

> 리눅스의 개발이 모두 닷넷 프레임워크 바탕으로 이루어질 때

누가 그런 얘기하던가요?
일부러 무언가를 설정해 놓고 설정해 놓은 것에 대해서만 얘기하는 듯한 인상입니다.
리눅스(오픈소스 커뮤니티)가 어떤 정책하나로 프로그램 만드는 곳입니까?
간단히 말하면 자기들 만들고 싶은거 만드는 겁니다.

그런것들중에 오픈소스 자바가 있는 것처럼 오픈소스 .NET도 만들어보자(모노)
그런 것이라 할 수 있는데
MS가 어떻게 하던 간에... Mono프로젝트쪽에서 말했듯이
그것이 MS에 의해 바뀐다 해도 지금 상태의 것만으로도 충분히 능력있는 개발환경을 오픈소스는 가질 수 있게 될 것입니다.

(자바쪽으로 비유하면) 그런데 뜬금없이
그렇게 해서 리눅스 프로그램을 모두 자바로 만들어야 한다면
SUN의 정책에 놀아나겠군요.
그래서 자바 반대합니다.
라고 그러는 소리 같군요. >.<

익명 사용자의 이미지

그런가요? 사실 이 부분에 대해서는 어떤 확실한 방향이 설정되지 않은 것으로 알고 있습니다만 최소한 그놈 플랫폼에 대해서는 닷넷 플랫폼 기반으로 전환하는 논의가 있는 것으로 알고 있습니다. go-mono사이트의 FAQ의 그놈과 모노의 관계에 대한 부분에서도 다만 모노가 아직 준비되지 않았다는 점을 강조하고 있을 뿐 그놈 개발자들이 닷넷으로 옮겨가는 문제에 대해 부정하고 있지는 않습니다.

제가 생각하는 문제점은 만일 그놈과 같은 주요 리눅스 플랫폼의 개발환경이 닷넷 중심으로 움직이고 닷넷의 방향성이 MS에 의해 영향받을 수 있다면 결국 리눅스 조차 MS에 의해 조정될 수 있는 가능성입니다.

아무도 그놈이나 KDE를 자바 기반으로 바꾸자고 말하지는 않지만 만일 그렇다면 저는 여기에도 반대할 것입니다.

익명 사용자의 이미지

제가 이곳에 객관적인 바라봄을 촉구하는 글을 올린후에 많은 분이 반응을 보여 주셨는데
여기에 있는 글을 읽어보니 두 부류군요.
닷넷 지지자와 반대자.
그런데 원래 시작글을 올린 분은 이런 취지가 아니였던 것 같은데요.
이곳이 리눅스가 닷넷을 끌어안는것에 대해 논한다면 거기에 왜 자바개발자가 나서서 이런저런 불평을 하시는지 이해가 가지 않네요.
그들의 주장 맥락은 자바가 있으니 리눅스가 닷넷을 끌어안을 필요가 없다는 것인양 비관적 전망과 MS의 어두운 과거를 들추기에 여념이 없으니 정말 한심합니다.
이런 말하기는 뭐하지만 이곳 관리자도 좀 문제가 있어 보입니다.
특정글에 -1을 부여한 이유가 뭔지? 그 글들을 읽어보니 도무지 모르겠네요.
자신의 의사에 반한다고 그렇게 멋대로 게시판을 관리해도 되는 건지 묻고 싶네요.

익명 사용자의 이미지

>>자바가 있으니 리눅스가 닷넷을 끌어안을 필요가 없다는 것인양

최소한 저는 그런 논지로 글을 올린적이 없습니다. 만약 아래 J2EE가 언급된 글들이 그런 식으로 읽혀진다면 제 표현에 문제가 있거나 님께서 무언가 오해를 하신 것 같군요.

>>MS의 어두운 과거를 들추기에 여념이 없으니 정말 한심합니다.

이 부분은 분명 정당한 이유가 있습니다. 모노가 MS가 사활을 걸고 추진하는 차기 개발 프레임워크/어플리케이션 플랫폼을 포팅하는 이상 MS의 영향력에 대한 논의는 모노와 관련이 있는 주제 아닐까요? 물론 여기에 찬성할 수도, 반대할 수도 있지만 논의 자체가 한심하다고 생각하신다면 이해가 가지 않습니다.

>>특정글에 -1을 부여한 이유가 뭔지?
게시판 운영은 제가 상관할 바는 아니지만 최소한 논점과 관계없는 똑같은 주장을 도배 한다던지 반말과 인신공격을 포함하는 글에 -1을 주는 것은 정당하다고 봅니다.

그럼~

익명 사용자의 이미지

저는 자바개발자 분들의 태도가 한심하다는 것입니다. 가령 잘 모른다면 공부를 하시는 것이 우선일 것이고 그럴 의도가 없이 무조건적으로 비난한다면 아래 어떤 분의 글처럼 밥그릇 싸움밖에 더 되겠습니까?
그리고 반론은 상대가 있으니 이어지는 것인데 한쪽에 일방적으로 -1점을 부여하여 부정적 인식을 심어주는 것은 공정하지 못하기 때문입니다.
즉 관리자는 그렇게 함으로써 은연중 한쪽을 편드는 것입니다. 저는 그 점을 지적한 것입니다. 이전부터 다른 주제에서도 그런 경향을 보아왔는데 저는 이곳이 특정한 한 사람에 의해 관리되는 문제점이라 생각되는 군요.

권순선의 이미지

오해 없기 바랍니다. 점수 변경은 특정 의견을 편들고자 함이 아니라 정상적인 논의를 가로막고 일방적으로 자기자신의 의견만을 관철하려 하는 lamp님을 막고자 한 것이었으며 제가 점수를 변경한 글은 모두 lamp님이 올린 글입니다. (익명으로 올라오긴 했습니다만 IP address가 동일하므로 lamp님이 올린 글이라 확신할 수 있습니다.)

그리고, lamp님께서는 부디 네티켓을 지키면서 글을 올려 주시기 바랍니다. 누구든 각자 생각은 자유지만 그 생각을 다른 사람에게 그런 식으로 강요하는 것은 지나치다고 봅니다. 저는 이 사이트의 관리자로서 당신의 그러한 행태에 오래전부터 점수변경 및 IP address를 막는 등의 조치를 계속해서 취해 왔습니다만 특별히 달라진 것 같지 않네요. 최소한의 예의는 지켜 주시기를 부탁드립니다. 당신 한사람 때문에 제 시간을 들여 가며 이곳을 관리하는 것도 제게 상당한 시간낭비이니까요.
--
WTFM :-)

keizie의 이미지

토론글 관리는 여러 사람에 의해 이루어집니다. 점수제를 도입할 때 점수 메기는 권한을 몇 사람에게 부여했습니다.
--
from [ke'izi] : where is [r]?

익명 사용자의 이미지

>> 저는 자바개발자 분들의 태도가 한심하다는 것입니다. 가령 잘 모른다면 공부를 하시는 것이 우선일 것이고 그럴 의도가 없이 무조건적으로 비난한다면 아래 어떤 분의 글처럼 밥그릇 싸움밖에 더 되겠습니까?

제 주장이 무조건 올바르다고 생각하지는 않지만 닷넷이나 모노에 대해 무조건적으로 비난한 적도 없다고 판단되는데요... 제 글에서 올바르지 않은 부분이 있고, 님이 저보다 그 방면에 더 많이 알고 계시다면 덮어놓고 한심하다고 비방하기 보다는 오류를 지적을 해주시기 바랍니다.

제 생각에는 님이 아래 글들을 정확히 읽어보지 않았거나 편파적인 시각을 가지고 있는 것 같군요.

익명 사용자의 이미지

저는 당신께서 올린 글이 사실보다는 추측에 가까운 내용이 다수 있어서 드린 말씀인데 자신의 글을 되돌아 볼 자세가 부족한 것 같으니 당신과는 더 이상 대화가 힘들 것 같네요.

익명 사용자의 이미지

논점에는 반박을 못하면서 난데없이 싸잡아서 한심하니 대화가 안되는니 하신다면 저도 더 이상 이야기를 계속할 생각없습니다.

논리에는 논리로 반박하면 됩니다. 그게 그렇게 어렵나요?

익명 사용자의 이미지

전혀 논리적이지 못한 분께서 논리논리하시니 웃음이^^

김용욱_의 이미지

한심합니다. 여기가 토론장인지 궁금해지게 만드는 말을 마지막으로 남기셨군요.
--
Lit.
동명이인이신 분이 계셔서 닉으로 합니다.

L.I.T

익명 사용자의 이미지

계속 지켜봤는데... 당신 참 예의가 없군요.
읽는 사람 짜증납니다.

익명 사용자의 이미지

저는 그런 것을 느끼지 못하겠는데요? 오히려 닷넷을 지지하는(모노가
아니라) 한 사람이 여기에 있는 듯한 기분이 들었습니다.(아니면 자바에
한이 맺혀 있거나... :-)

제가 보기엔 VM을 구현하는 것은 현실적으로 가능할 것으로 생각이 됩니다만
거의 Win32 API에 기반을 둔 듯한 .Net Framework가 완벽하게 이식되는
것이 가능할지는 의문입니다... 기존에 MS가 해 오던 정책을 보면 기존의
것과 한 방향으로는 호환이 되도록 하지만 반대로는 불가능하게 하거나
만드는 것을 원천적으로 방해하는 (Embrace and Extend, CIFS Spec에서
GPL을 차단한 것) 정책을 써 왔기 때문이지요. 아마 윈도 이외의 플랫폼에서
잘 돌아간다면 그 구현체를 그냥 순순히 잘 돌아가도록 둘 것 같지는 않습니
다. 특히 GPL이라면 말입니다...

익명 사용자의 이미지

그게 중요합니까?
리눅스를 사용하는 데 있어서 제약을 벗어나는 것이 먼저라고 생각하는 데요.
마소의 정책이 어떻든 그것이 중요한게 아니고 리눅서에겐 리눅스가 어떻게 시장의 주류로 자리잡느냐가 먼저 아닙니까?
사실상 썬에서 개발한 자바는 지금까지 전혀 그런 역할을 하지 못했습니다.
마소가 닷넷을 개발하고 그것이 리눅스로 전이되어서 리눅서의 저변확대에 기여한다면 그것 가지고 비난할 이유는 전혀 없지 않습니까?

익명 사용자의 이미지

저같은 종류의 리눅서는 리눅스가 어떻게 시장의 주류로 자리잡느냐에는 별 관심이 없습니다. 그리고 아마 저같은 종류는 꽤 되는 걸로 알고 있습니다. 리눅스 공동체를 유지하는데 충분할 정도로 말이죠.

몇번에 걸쳐서 여기 포럼에서도 논의됐던 문제이지만 이건 존재론적인 문제입니다. 시장의 주류가 되고 대중화가 되는것 좋죠. 하지만 이건 리눅스로서 시장의 주류가 되고 대중화가 될때 의미가 있는 거죠. 이럴 경우에는 gnu/linux라고 정식 이름을 불러야 겠군요. 어쨌거나 리눅스가 오픈소프트웨어 혹은 거대 회사들의 product을 품고있는 대리모 소프트웨어가 아닌 자유소프트웨어이길 바라는 제 입장에서는 동의할 수 없습니다. 모노가 기회가 아닌 위협으로 보이는 것도 실은 모노가 사람들을 무의식 중이 님과 같은 생각으로 이끌지 않을까 하는 걱정이 있어서입니다.

님께서는 이해도 동의도 안하시겠지만 저같은 종류의 사람에겐 자유가 gnu/linux가 품어야 할 가장 첫번째이며 마지막 목표입니다. 그리고 gcc 팩키지 하고 ^^;

MS이든 IBM이든 gnu/linux에 기여한다면 고맙지만 소유하겠다면 거절해야한다고 생각합니다. 이런 거절에 힘을 보태주는 것은 작지않은 아주 명백한 기여라고 생각합니다.

익명 사용자의 이미지

>>MS이든 IBM이든 gnu/linux에 기여한다면 고맙지만 소유하겠다면 거절해야한다고 생각합니다. 이런 거절에 힘을 보태주는 것은 작지않은 아주 명백한 기여라고 생각합니다.

명언이군요 :) 어디에 써먹어야겠습니다.

익명 사용자의 이미지

리눅스가 선택할 수 있는 방향이 닷넷 아니면 자바인가요? 이왕 자바 이야기가 나왔으니 첨언하지만, 최근들어 외국을 중심으로 서버시장에서 리눅스의 입지가 늘어나는 건 J2EE의 덕입니다. 중대형 어플리케이션을 개발하는데 php나 아직 완성도 안된 모노를 쓰는 경우는 거의 없으니까요. 원하신다면 통계 자료나 분석 기사도 얼마든지 찾아드릴 수 있지만 토론의 성격과 맞는 내용인 것 같지 않습니다.

>>마소의 정책이 어떻든 그것이 중요한게 아니고 리눅서에겐 리눅스가 어떻게 시장의 주류로 자리잡느냐가 먼저 아닙니까?

이 부분은 개인의 시각 차이니 만큼 답이 나올 수 없는 문제이지만, 극단적으로 리눅스에서 익스플로러로 브라우징을 하고 MS오피스를 쓰며 VisualStudio.NET으로 개발을 한다면 저는 더 이상 리눅스를 쓰고 싶지 않습니다. '선택의 자유'는 리눅스의 중요한 존재의 이유 아닌가요?

익명 사용자의 이미지

linux for PC is very important.
server os market is smaller than desktop os market
now linux developers must give serious consideration to applications for desktop linux

linuxers like you are menbers of a minority party
you are possessed with illusion that all other linuxers will sympathize with your thought

익명 사용자의 이미지

PC시장이 중요하지만, 서버 시장도 최소한 클라이언트 시장 만큼은 중요하다고 봅니다. 제 의견이 님의 의견보다 더 소수의견이라고 생각하지도 않지만, 소수의견이면 무시해도 된다는 말인가요?

그리고 설사 리눅스에 있어서 서버시장이 아무것도 아니라 해도 그게 닷넷과 무슨 관계가 있지요?

논리적인 주장이라면 님과도 얼마든지 토론할 의향이 있지만, 상대방 의견을 무시하고 자기 주장만 반복하는 건 의미가 없습니다. 닷넷이나 모노를 옹호하고 싶으시다면 인신공격이나 동어반복을 빼고도 얼마든지 할 수 있습니다.

익명 사용자의 이미지

my IP is rejected from here.

visit my homepage
In my guest book
We go into a discussion

익명 사용자의 이미지

I am lamp
my homepage is http://lamp.is.dreaming.org

익명 사용자의 이미지

저는 솔직히 JVM이나 닷넷이 왜 좋은건지도
잘 모르겠어요...
리눅스에서 그냥 C써서 서버 만들면 안되나...
그래야 고성능이 나올것 같은데..

대규모어플리케이션을 c로 만들기가 그렇게
힘든건가 봅니다...

예전에 밥먹고 살려고 자바로 간단한 서버를 만들
었던 적이 있었는데...
자바가 더 쉽게 짤수 있다는걸 제외하면
큰 차이는 못느꼈읍니다.
그러니까 아주 강력한 필요성이랄까..

하긴 그렇게 따져보면 MFC로 짜나
닷넷으로 짜나 마찬가지니..

더 편하게 대형프로그램을 짤수 있다는게
엄청난 장점이긴 장점인가 봅니다.

익명 사용자의 이미지

서버는 자바가 더 빠른 경우도 많습니다 :)
물론 짜기 나름이라서 직접적인 비교가 불가능하다는게 문제지만요~

익명 사용자의 이미지

비슷한 일을 하는 라이브러리로, 비슷한 일을 하는 프로그램을 짠다면, 당연히 native로 짜는게 속도가 빠르지 않나요?

자바로 짜는게 빠를수도 있다는 것은 어떤것을 의미하는지 궁금하네요.. 자바가 나쁘다는 것이 아니라 vm이니 어쩔수 없는 한계라고 생각하는데, 의외로 자바로 짜는게 빠를수 있다는 사람이 많아서 머리가 헷갈리는 중입니다...

아니면, 자바라는 "언어의 특징"때문에 더 좋은 질의 프로그램 (더 낳은 알고리즘을 사용하는) 을 짤 수 있다는 건가요?

제가 자바로 프로그램을 많이 하지는 않았지만, 항상 짤때마다 저놈 참 무지하게 느리네... 하는 생각만 받았었는데. 고견 부탁드립니다.

익명 사용자의 이미지

다이나믹 컴파일레이션 때문입니다. 정적으로 컴파일 한 것 보다
동적으로 만든 것이 빠를 때가 있기 때문이죠. 특히 서버쪽의
작업처럼 CPU타임을 적게 쓰고 비슷한 일을 계속 반복하는 경우에는
그 이점이 잘 드러납니다. 물론 C로 해도 빠르게 만들 수는 있습니다만
크게 차이가 나지 않습니다. 단지 C로 하면 더 작은 리소스를 차지하게
만들 수 있겠지요. 예를 들어 웹서버나 메일 서버 같은 경우는 각각
최대의 병목은 네트워크와 디스크입니다(물론 잘 못 짜서 커널상의
네트워크 스택이 병목이 될 수도 있지만 이런 것은 논외로 하고...).
따라서 반복적인 일을 얼마나 효율적으로 잘 하느냐가 중요하게 되는
것이지요. 이경우 (물론 C, JAVA 모두 최선을 다해서 만든 경우에)에는
아마 속도가 같거나 거의 차이가 없을 것입니다. 그러나 현실적으로 C로
효율적인 네트워크 프로그래밍을 할 줄 아는 사람들은 드뭅니다. 이것은
Portability의 이슈도 있고 해서 한 쪽에 완벽하게 최적화를 하지 않기
때문이기도 한데(예를 들어 Apache가 그렇습니다.) 이런 쪽으로는 JAVA의
라이브러리들이 더 잘돠어 있습니다. 때문에 JAVA가 더 빠른 경우가
나오기도 하지요...

익명 사용자의 이미지

Java와 C를 비교하고 있는데 C가 아니라 C++아닐까요?
C는 C++보다 빠릅니다.

익명 사용자의 이미지

사실 자바나 닷넷이 특히 복잡한 대규모의 서버환경에서 유용한 이유는 성능은 아닙니다. 성능이라고 해도 결코 단순 연산속도를 이야기하는 것 보다는 클러스터링 등을 이용한 scaleability를 말합니다.

닷넷도 거의 마찬가지지만 제가 친숙한 J2EE의 예를 들자면, 데이터베이스만 보더라도 개발자는 실제 어떤 데이터베이스가 쓰이고 테이블 구조가 어떻게 되어 있는지 등등에 신경쓰지 않습니다. RDB와 객체지향 언어사이의 gap도 컨테이너가 엔티티빈이라는 방식으로 메꾸어 줍니다. 이렇게되면 개발자는 일일히 구체적 데이터베이스 환경에 구애받지 않고 순수하게 객체 수준에서 생각하고 개발할 수 있습니다.

J2EE에서 대표적으로 보안, 트랜잭션, 분산, persistence의 관리는 컨테이너가 처리합니다. 닷넷도 persistence부분을 제외하면 거의 유사한 것으로 알고 있습니다.

이런 식으로 닷넷이나 J2EE와 같은 프레임워크를 사용하면 하위레벨의 복잡성을 감추어 주는 추상화 계층을 제공함으로써 유지보수와 개발에서 상당한 시간과 비용의 절감이 가능합니다.

scaleability를 무시하면 가장 빠른 어플리케이션은 웹서버부터 db 연동까지 모조리 C로 어플리케이션에 최적화해 구현하면 되겠지만, 이런 방법이라면 초급 자바, 혹은 닷넷 개발자가 좋은 IDE로 1-2시간에 가능한 일을 C를 마스터한 개발자가 1개월에 걸려 해결해야 합니다. 또한 이런 코드는 원래 개발자 아니면 파악하기조차 쉽지 않습니다.

기업 입장이라면 C의 고급인력을 쓰는 비용으로 하드웨어를 업그레이드하는게 좋겠지요.

익명 사용자의 이미지

lamp씨 당신이 이겼습니다. 이제야 고백하지만 저나 다른 자바 개발자들은 모두 썬이 세계 정복을 위해 고용한 끄나풀입니다. 저는 매일 커피를 10잔씩 마시고 아침 저녁으로 커피잔에 절을하는 자바 광신도입니다. 자바 이야기만 나오면 끝까지 추적해서 욕설과 도배로 대응하는 정의의 사도인 당신의 노력에 감복했습니다.

모노 만세! 모노천국 자바 지옥!!

다른 자바 광신도들도 빨리 자수해서 모노 믿고 광명찾기를 바랍니다.

당신이 이겼으니 도배는 좀 그만하시지요

익명 사용자의 이미지

저(전 Lamp가 아님)같은 경우는 자바가 싫다기 보단 SUN이 싫은 경우죠. SUN의 그 속보이는 행태를 보면 아주 웃기다 못해 재미있습니다.

자바 처음 나올때, 무료에다 깔끔한 라이브러리 스택, 자바 가상 머신의 이식성, Simple한 OOP등 누가봐도 아주 괜찮은 환경이었습니다. 반응이 좋자 내친김에 NC(Network 위주로 기능이 단순화된 PC, 게다가 HDD가 없음, 쇼킹!!)니 뭐니하며 분위기 띄우더니, 우리를 세뇌하기로 작정을 했는지, NC가 미래를 지배할거라나 뭐라나. -_-; PC는 없어지고, NC에다 강력한 워크스테이션 서버로 세계가 구성될거라는 해괴망칙한 말도 안되는 자기네들만의 상상을 해대고.. 자기네들이 파는 값비싼 워크스테이션(솔라리스 유닉스를 탑재한, 그때 최저가 사양의 워크스테이션의 가격이 무려 3천만원정도였음) 팔려는 노골적인 속셈을 마치 그것이 대세인양 나불거리고.

마이크로소프트도 SUN의 시도에 귀가 솔깃했는지 NetPC라는 걸 만들어서 어쩌고저쩌고 해대기까지. SUN이 SW(Software)영역에 침범하니 본능적인 방어 태세인지 "우리도 HW(Hardware)로 진출한다"라는 무언의 압력이었을지도.

결국 NC고 NetPC고 간에 씨도 안먹히는 소린 어느샌가 슬그머니 자취를 감추고.

그러는 시기 인텔의 팬티엄III,팬티엄IV, 제온등에 힘입어 PC가 거의 워크스테이션 성능(인텔 CPU는 완전한 RISC가 아니지만 일단 Clock이 받쳐주니 무지 빠르죠)에 육박해지자, 마이크로소프트, 중저가 PC 서버와 더불어, 오히려, 진짜 오히려, 어부지리, 횡재!!, 덩달아 컴팩과 HP도 엄청 커졌죠. HP와 컴팩이 마이크로소프트 욕하는 경우는 없죠. 아주 절친한 동반자 그 이상이지요. 인텔, 마이크로소프트, 컴팩, HP는 그야말로 끈끈하다라는...

윈텔 진영의 승리!! 마이크로소프트 성장의 반은 사실상 인텔이라고 봐도 과언이 아닐듯. 아직까지도.

SUN이 PC 시장 죽일려고 자바 만든건데, 역으로 마이크로소프트가 가격/대비 성능이 우수한 윈도우NT, 윈도우2000으로 중.저가형 서버 시장을 장악하게 되니. SUN 위기. 맥닐리 맨날 불공정 거래니 뭐니 목청 높여가며 "타도 마이크로소프트"만 외치고, 결국 돈에 쪼달리는지 Linux에 있던 무료 Office 프로그램(스타오피스) 구입해서 유료로 팔고.

PC 시장 죽일려고 하던 SUN이 오히려 PC용 솔루션을 제공하는걸보니 역시 그들이 행했던 과거의 행동들에 대해 스스로 잘못을 시인하는 꼴.

이런 와중 즉 마이크로소프트가 인텔CPU를 탑재한 중.저가 PC 서버 시장을 장악하자, 위기를 감지하고 긴장하기 시작한, 저기 높으신 IBM 어르신이 리눅스(공짜여서라기 보단 인텔 CPU를 지원하는 유일한 유닉스 계열의 운영 체제라서)로 어쩌고저쩌고. IBM이 리눅스 지원한다하니 전세계적으로 리눅스 붐(Boom) 불고. 결과적으로 리눅스 많이 성장. 역시 돈이 풀려야...

참고로 IBM은 성능이 우수한 AIX(RS6000시리즈에서 사용하죠)라는 유닉스형 운영체제를 가지고 있습니다. 그러나 이것은 인텔 CPU에서는 작동하지 않지요. 물론 작동해야할 이유도 없죠.

요즘 제가 관심을 가지는 부분은 마이크로소프트가 고가형 서버 시장에서 어떤 승부를 낼지입니다.

그동안의 전투가 마이크로소프트의 안방에서 이뤄졌다면 이젠 SUN의 안방에서 벌어질 차례이지요. 마이크로소프트의 핵펀치에 맞아 나가떨어지지 않을려면 SUN은 더 긴장해야 할겁니다. SUN의 자바나 스타오피스같은게 중요한게 아니라 자기의 생존권이 걸려 있는 고가형 서버 시장을 지키는게 급선무이겠지요.
마이크로소프트는 서버 PC를 직접 팔지는 않기에, 엄밀히 말해서 윈텔 진영에 대한 긴장을 해야겠지요. 인텔의 서버용 64비트CPU인 이태니엄이 향후 어떻게 되느냐에 따라 운명이 결정이 날겁니다.

70년대를 장악했던 Apple 컴퓨터가 PC에 밀려 망했듯이, SUN이 안망하리라는 보장이 없습니다. 한 몇년 전부터 PC가 망하니마니 말이 많았는데 아이러니 하게도 PC가 모든걸 장악해 나가는군요. 바람직한 현상이라고 생각합니다.

만약 SUN의 의도대로 지금 이 시점에 NC+워크스테이션이 활개를 친다면, 우리는 여전히 컴퓨팅 작업을 하는데 값비싼 비용을 지불하고 있을겁니다. 요즘처럼 고성능의 PC를 50만원 정도에 구입할 수 있는데 일조를 한건 분명히 윈텔 덕분입니다.

인정할건 인정해야하죠.

암튼 이렇게 세상은 흘러왔습니다.

익명 사용자의 이미지

딴지 하나 걸께요.

Java가 PC시장 죽이기 위해서 나왔다고 하셨는데 무슨 근거인지?
글구 스타오피스가 무료로 나온것은 제가 들은바로는
MS가 SUN에게서 JAVA스팩을 쓰게 허락받은뒤에 얼마후 갑자기 SUN에서 관리하는 표준안을 무시하고 만들기 시작했습니다. 무슨 소리인고 하니 MS의 엄청난 사용자를 무기로 JAVA스팩을 휘저어 놨다는 거죠. 결국 SUN에서 법적으로 못쓰게 만들었지만 이미 상당히 흙탕물이 튀고, SUN의 화를 돋구웠죠.(이렇게 말해서 그렇지 상당히 싸가지 없는 짓이죠.) 그 뒤 JAVA와 비슷한 C#이 나왔습니다.
SUN은 독일의 스타오피스 소스를 사서 유닉스 시장에서 팔려고 하다가 갑자기 그냥 공개해버렸습니다. 물론 나중에 버젼을 달리해서 팔려고 하지만.

주장은 아니고 그냥 정황을 주욱 적어봤습니다.

사실 MS를 싫어하는 이유도 OFFICE 같은 걸봐도 독과점입니다.
우리나라 아래아한글 죽을때까지 저가내지는 공짜로 팝니다 MS위드
다른 나라 엄청나게 비쌉니다. 우리나라 MS위드 쌉니다.
하지만 경쟁상대 없어질때까지만 입니다.
가격으로 누릅니다. 질은 둘째 문제입니다.

그리고, OS를 무기로 삼습니다. OS에 핵심 라이브러리를 무기로 삼습니다.
많은 프로그램을 팔기위해 버젼 바뀔때 한번씩 함수를 인수 위치 바꿉니다.

한마디로 욕나옵니다.
제 생각은 MS 욕먹을만하다는 거죠.

익명 사용자의 이미지

딴지요...
NC의 전도는 SUN이 아니라 ORACLE 회장이 주도했져.
클라이언트측에선 하드웨어 비용증가를 막는다는 장점인걸로 아는데.
나름대로 괜찮은 아이디어였지만... 당시 네트워크 인프라가 이를 따라가지 못해 실패한걸로 압니다.
그리고 애플은 망하지도 않았고 NC가 활성화 되었다면 우린 하드웨어 업그레이드에 몇십만원씩이나 소비하지도 않았을지도 모른다는 생각이 드네요.

익명 사용자의 이미지

논리가 마치 매우 잘 맞는 듯 하지만, 비슷한 얘기를 MS에다 대고도 할 수 있다고 생각합니다. 단 차이점은 MS는 돈이 많아서 성공한 일이 많다는 것이지, 둘 다 기업의 이익을 위해서 하는 짓은 비슷한거 같은데, SUN은 실패했다는 이유만으로 그렇게 미움받아야 하는 것은 아닌 듯 합니다.

익명 사용자의 이미지

역사를 오늘의 시점에서 재구성하면 과거의 사건들은 모두 음모 아니면 어리석은 희극이 되겠죠. 오로지 현재의 승자만이 현명하거나 정상적인 길을 걸은자로 남고 말이죠.

NC에 대해서 얼마나 알고 계신지 모르겠지만 원래 NC는 home PC의 대체품이라기 보단 office PC의 대체품으로 나온겁니다. 미래에는 가정에서도 NC를 쓸꺼라는 가정을 하긴 했지만 당시의 네트웍 상황에서 정신병자가 아니라면 당장 가정에서 NC를 써야만 한다고 주장하는 인간은 없었습니다. 사실 NC는 상당히 매력적인 개념입니다. 보안, 자원관리, 시설투자비 면에서 월등했으니까요. 그렇기 때문에 유수의 컴퓨터 회사들이 달라붙어서 개발에 열을 올렸고 마이크로소프트도 lightweight PC의 개념을 도입할려고 했던 겁니다. 그러나 NC의 가격이 PC에 비해 그다지 저렴하지 않은 반면 중앙집중화된 서버나 스토리지 구축에 거액의 새로운 비용이 들어가고 또 그놈들은 업데이트가 힘들다는 점, 자기만의 장비를 가지고자 하는 개인의 욕망, 관리책임 회피를 원하는 책임자들의 욕구가 맞아 떨어져서 NC는 사멸하지요. 이건 네트웍의 시대로 진입하면서 시스템 설계자들이 겪은 한바탕의 홍역이었고 새로운 시대를 맞이하는 실험이었습니다. 팔짱을 끼고 그건 어리석은 짓이야만을 외치는 사람은 언제나 역사의 대로에서 갓길에 정차해 있을 뿐입니다. 현재 가능한 기술을 쏟아 부어 달리고 달려서 낭비도 하고 실패도 해봐야 다음 패러다임 쉬프트가 도래할때 edge에 설수 있게 되는 겁니다.

그리고 윈텔 덕분에 싼 시스템을 산다니 심한 코미디군요. 오히려 AMD와 한컴, os2, 리눅스와 자바에 감사해야 겠지요. NC같은 도전이나 경쟁자가 없었다면 싼 시스템이나 성능의 향상 따위는 기대하기 힘들었을 겁니다. 어차피 그런 정체는 시장이 있는 한 일어나지 않았을 공상에 불과하지만요.

익명 사용자의 이미지

(저는 위에 글쓴 사람임)

지어낸 이야기도 아닌데 재구성이라고 폄하하는건 옳지 않아 보입니다. 말도안되는 소리를 재구성해서 그럴듯하게 포장하는건 신문 기자나 하는 일 아닌가요? 기자들은 자기의 논조를 펼치고 그것을 증명이라도 하듯이 인터뷰에서 필요한 말만 잘라서 보여줍니다. 인터뷰했던 사람이 기자와 과연 같은 생각을 가지고 있는지는 아무도 모른다는.

객관적으로 바라보는 것과 그 객관적 사실을 해석하는건 별개의 문제이겠지요. 아마 님과 저는 그 사실을 해석하는 관점이 다른 것이겠지요.

전 SUN을 음모의 마왕이라고 보고있기는 합니다. 다만 제가 모든 사태를 끼워 맞춰서 음모의 마왕으로 구성하는게 아니라 이미 음모의 마왕이기에 그들의 행태를 까발리는 것 뿐입니다.

음모하면 Microsoft도 만만찮겠죠. 만약 SUN의 음모만 까발렸다고 기분나쁜 것이었다면 Microsoft도 음모의 마왕이다라고 님이 까발리면 됩니다. 전 뭐 Microsoft를 애써 두둔할 생각은 없습니다.

그리고 NC+Workstation에 대해서는 여전히 비관적인 자세를 견지할 수 밖에 없습니다. 님의 말처럼 솔깃할 부분이 없는 것은 아니요. 그러나 대체적으로 NC는 비관적으로 비판받아왔습니다. 극단적으로 말하자면 이것은 옛날의 Dummy Terminal+Main Frame과 개념적으로 보면 별 차이도 없지 않습니까? 이것은 패러다임의 변화는 커녕 과거로 도퇴되는 모양새였습니다.

굳이 의미 부여를 하나 한다면 PC는 하나의 SW를 해당 PC마다 깔아야하므로 n개 PC라면 n개의 라이센스를 구입해야 하지만 NC+Workstation의 경우에는 Workstation에다 하나만 깔면되니까 SW 비용이 1/n으로 줄어들지요.
이것 즉 SW 공유가 NC의 진정한 자랑거리였는데, 그런데 만약 SW에 대해서 1/n같은 혜택을 받아도 Workstation의 가격이 비싸다면!! 언제나 그랬듯이 Workstation 살 돈 있으면 그냥 n개 SW 사는게 낫죠. 게다가 각 PC마다 그 SW가 다 깔려 있을 필요도 없으니 n은 n보다 작은 값이겠죠.

그럴듯 하지만 결국 그럴듯하지 않았던 NC+Workstation의 단면을 그대로 보여줍니다.

그리고 제가 제일 싫어하는 논리적 전개 방법이 마지막 부분에서 보이는군요. 윈텔 덕분에 싼 시스템을 사는건 아니다라는 부분.

SUN의 값비싼 워크스테이션에 비해 가격이 싸다라는건데 갑자기 AMD, Linux 얘기를 꺼내면 짜증나지요. 님의 말을 극단적으로 해석하자면 AMD나 Linux가 없었다면 오늘날 저가형 PC 서버 시장에서 윈텔이 손도 못낼밀었다는 말인건가요? 제 생각에는 AMD나 Linux가 없었다면 인텔 CPU와 Windows OS의 가격이 아무래도 조금더 더 비쌌겠지만 그렇다고해도 SUN의 그것에 비하면 여전히 저가(저가격)입니다. SUN의 머신이 얼마나 비싼지 감잡으면 더 이해하기 쉬울겁니다.

그리고 비아냥 거림(코미디니 뭐니 하면서)은 보는건 이게 마지막이 되기를 바랍니다.

익명 사용자의 이미지

NC는 님께서 얘기한 그 n개의 더미클라이언트의 수가 무지하게 많은 경우를 가정한 놈입니다. 그리고 중앙집중화가 패러다임의 변화이긴 커녕 과거로의 도퇴라는건 작금의 기업 컴퓨팅이 웹서버(라기 보다는 애플리케이션 서버) 중심으로 집중되고 있는 상황을 간과하는 측면이 없지 않나요? 예전엔 다운사이징 하면 메인프레임을 말씀하신 값비싼 워크스테이션 무더기로 바꿔서 지사별로 부서별로 node를 만드는 거였다면 요즘은 몇개의 잘나가는 unix 서버로 바꿔서 주요지점에 떨구고 나머지들은 가장 가까운 곳에 붙도록 하거나 아님 아예 IDC 처럼 한곳에 몰아놓고 집중투자 하는게 추세 아닌가요? 어차피 하늘아래 새로운 것은 없다고 역사는 정반합의 수렴과정 아닐까요? NC는 변화된 상황에 대한 잘못된 대처였는지 모르겠지만 상황이 변화한건 사실입니다.

그리고 윈텔덕에 싼 시스템을 쓴다는 말이 그 덕에 비싼 SUN 장비 안써도 된다는 말씀이라고 하셨는데? SUN이 안 비쌌으면 PC 서버라는 개념자체가 생기지도 않았을 것이고 SUN이 없었다면 윈텔이 PC 서버를 그 가격에 팔고 있을 겁니다. 윈텔이 없었다면 amd, DR-Dos 쫌 뒤엔 amd,os2 뭐 이런 것들이 윈텔의 자리를 대신했을 테고요.

시장에 요구가 이윤을 담보해 주니까 기업들이 몰려들었고 윈텔은 그 과정에서 한 피크를 장악했을 뿐입니다. 왜 시장이 그들에게 감사해야 하죠?
시장에 가서 쭉늘어선 빵집중에 한집에 들어가서 빵을 사먹는데 그 가게 주인이 넌 내덕에 이빵 먹는거야 고마운줄 알아하면 화를 내던가 비아냥 거리던가 아님 딴 가게에 가버리겠죠. 전 비아냥 거리고 싶네요.

페이지