리눅스, 닷넷을 끌어안아라
http://www.zdnet.co.kr의 기사내용 일부입니다. 전체 내용은 관련 링크를 참조하십시오.
---
필자가 지난 번 컬럼에서 지적했듯이 MS가 추진중인 닷넷 프로젝트는 MS는 물론 비MS 플랫폼에서도 공동으로 사용할 수 있는 표준 개발 틀로 성장할 것이라고 생각한다. 하지만 닷넷의 성장이 꼴보기 싫어서 키보드를 집어던지고 히말라야에서 셀파가 되기로 작정하지 않은 이상 닷넷같은 공통 개발 틀을 중심으로 전세계가 통합되면 얼마나 많은 이점이 있을 것인지 한번 곰곰이 생각해 보기 바란다. 닷넷을 닷넷에서는 다양한 프로그램 언어를 지원하고 있다는 점을 강조하는 차원에서 '소수 프로그램 언어의 구세주'라고 주장하는 바를 따져보자. 이처럼 다양한 언어를 지원하는 특성 때문에 닷넷은 리눅스를 포함해 많은 비MS 플랫폼과 응용 프로그램에게 행운을 가져다 줄 수 있을 것이다.
1. 닷넷은 여러 비MS 플랫폼이 더 큰 윈도우 개발 공동체에 연결되도록 해준다. 이렇게 되면 이들 플랫폼에서 일하게 될 개발자의 숫자도 증가될 것이다. 아래에 있는 글은 시미안의 창설자 미구엘 드 이카자가 생각하는 왜 리눅스에 닷넷을 설치해야 하는지에 대한 글이다.
- 윈도우 개발자들은 리눅스를 위한 코드를 작성할 수 있다.
- 개발자들을 윈도우 세계에서 리눅스 플랫폼으로 이끌어오는 것이 쉬워진다.
- 훈련용 교재나 교육용 교재, 문서들, 여러 가지 유용한 정보와 도움말 등이 이미 많이 나와 있다. 이것들을 이용하자.
다른 말로 하자면, 윈도우 개발자들이 리눅스를 위해 프로그램을 작성하는 것이 쉽다면 그들은 리눅스를 위한 프로그래밍을 할 것이다. 전혀 다른 API를 재교육 받는 것조차 개발자들은 개의치 않을 것이다.
게다가 닷넷을 받아들임으로써 다른 플랫폼들은 MS와 다른 여러 회사들이 닷넷 참고 문헌과 교육에 투자한 수십 억 달러의 비용을 덩달아 이용하게 되는 셈이다. 오랫동안 맥과 BeOS의 개발자였으며 '페퍼'라는 교재의 편집자였던 마텐 헤켈만이 최근에 한 인터뷰에서 말했듯이 MS의 문서들은 정말 괜찮은 내용을 담고 있다. MS는 다른 회사들이 하지 못하는 방식으로 개발자들의 욕구를 충족시켜준다. 이런 투자를 이용하는 것은 사업적인 센스가 아닌가. 사실 이런 투자는 사실 다른 플랫폼에서 이득을 볼 수 있는 공짜 돈이다.
결론적으로 비MS의 입장에서는 닷넷이 개발 비용을 절약해주는 셈이다. 저렴한 비용에다가 윈도우 개발자들이 넘어가야 했던 장애물도 많이 없어지기 때문에 더 많은 애플리케이션이 나올 수 있는 토양을 닦을 수 있다는 뜻이다. 네트워크 효과가 소비자들을 윈도우로 계속해서 유인하는 것이라면, 그 네트워크에 연결해 소비자들을 리눅스같은 플랫폼에 대해서도 한번쯤 고려하게끔 할 수 있는 가능성이 더 많아지는 것이다.
2. 비MS 플랫폼에서 MS 애플리케이션을 지원하는 것이 더 쉬워진다. 당신이 좋든 싫든 MS 애플리케이션은 현재 나와있는 소프트웨어 가운데 가장 인기 있는 제품이다. MS는 자사의 제품 가운데 대부분을 닷넷으로 전환할 계획이다. 그렇게만 되면, 그들이 비MS 플랫폼에서도 그것들을 사용할 수 있는 기회가 생기는 것이다. 그렇게 되면, 애플리케이션들이 윈도우 고유의 코드와도 호환될 수 있고, 또 윈도우에서만 쓸 수 있는 프로그램을 사용할 수 있게 될지도 모른다. 따라서 오피스를 완전히 사용할 수 없는 비표준 기능을 제공하는 회사들도 시장에 참여할 수 있는 기회를...
---
Ximian의 창설자 미구엘 드 이카자가 생각하는 왜 리눅스에 닷넷을 설치해야 하는지에 대한 글을 읽은 적이 있습니다. 여러분은 이것에 대해 어떻게 생각하시는지...
(위 글 쓴 사람입니다)따지고 보면 지독히도 보기 싫은 우리 옆집
(위 글 쓴 사람입니다)
따지고 보면 지독히도 보기 싫은 우리 옆집에 사는 할머니가 존재하기에 어쩌면 이 세계가 존재하고 있는 것일지도 모를일이지요.
북경에서 나비가 살랑살랑 거렸기에 LA 다저스 스타디움에 비가 오는지도 모를일이고 태양이 뜨겁게 타오르기에 안드로네다 은하계가 소용돌이 치는 지도 모를일입니다.
이런 관점에서 이 세상과 역사를 다시 보니 님의 말씀이 결코 틀린건 없군요.
님의 말씀 잘 이해했으니 이쯤해서 접는게, 권순선씨의 여가 활동 시간을 뺐지 않는 길이라 생각이 됩니다.
저는 시장이라는 필연이 윈텔이라는 우연을 통해서 발현되었다는 얘길 한겁니
저는 시장이라는 필연이 윈텔이라는 우연을 통해서 발현되었다는 얘길 한겁니다
왜 북경 나비가 여기 등장하나요? 혹시 물리학자들이 얘기하는 최초의 충격저럼 대류라는 필연이 나비의 날갯짓이라는 우연을 통해서 동작을 시작했다라고 하면 맞습니다. 대기가 존재하기에 대기안에서 운동하는 동식물이 있고 그 동식물의 운동이 다시 대기의 이동을 촉발시키는 매개가 됐다면 정확히 제 얘기하고 부합합니다. 한 나비의 날개짓 자체는 우연이지만 대기안에 존재하는 나비 자체가 필연적으로 운동하게 돼있다는 점에서 제 얘기하고 부합하지요.
하지만 SUN과 윈텔의 관계는 나비와 대기처럼 초거시와 미시를 왔다갔다하는 관계가 아니라 대등한 존재감을 가지고 있고 비교적 좁은 카테고리내에서 경쟁, 대체하는 관계이므로 직관적인 반면 나비와 대기는 증명해야할 길이 머나멀죠.
옆집할머니와 세계는 저로서는 모르겠군요.
전 님께서 NC가 순전히 썬의 음모였다에 대해서 NC가 등장한 나름의 이유가 있었다.라고 얘기했고. 윈텔은 어차피 기업으로서 시장의 요구에 따라야 했고 마침 그들이 간 방향이 시장이 원하는 바와 부합했기 때문에 지금의 위치를 차지했을뿐이니 그들에게 소비자들이 감사해야 할 이유는 전혀없다는 것이었습니다. NC에게 감사할 필요 없듯이요. 오히려 그런 우월적 지위를 그들이 행사하기 어렵게 견제한 경쟁업체들이 저로서는 더 고마운 존재라는 거였고. 윈텔이 소비자들이 싫어져서 시장을 떠나면 언제든 경쟁업체들이 그 자리를 매우고 새로운 업체가 그 업체의 경쟁업체로 떠오를 꺼라는 말씀이었습니다. 자본주의에서 너무나 자연스러운 일 아닌가요?
말씀을 접자는 요지는 이해하지만 저는 나비와 대기나 할머니와 세계처럼 직관적이지 않은 개체간의 관계가 아닌 명확히 경쟁, 대체 관계인 SUN과 윈텔, 윈텔의 경쟁업체들의 관계를 얘기한 겁니다. 저는 비아냥의 이유를 대는데 님께서는 비아냥만 보시는 것 같아서 좀 적었습니다.
끝으로 비아냥은 제 논지를 좀더 잘 보이게 하려는 의도였을 뿐이므로 기분 나쁘셨다면 정중하게 사과드립니다. 죄송했습니다.
옆에서 보는 사람으로서....아마도 '윈텔 덕분이다'라는 말씀은
옆에서 보는 사람으로서....
아마도 '윈텔 덕분이다'라는 말씀은 'SUN의 NC가 아니라 윈텔의 PC를 여전히 사용하고 있는 덕분이다'라는 의미인 것 같습니다. 그리고 그것은 윈텔의 의도이기도 했습니다. 즉 윈텔이 현재의 상황(=> NC + WS 등이 아닌 PC가 주류를 이루고 있는 상황)을 만들기 위해서 노력했고(물론 말씀하신 대로 더 큰 흐름 속에서 자신들에게 최선의 방향을 결정한 것이지만), 또 그것이 성공해서 현재의 상황이 되었으니, 이것은 윈텔 덕분이다...라고 하는 것은 그렇게 무리한 표현이라고 생각되지 않습니다.
그것을 굳이 회사 자체가 선한 의도가 있었는가의 의미로 해석하시는 것은 다소 오버하신 듯 합니다. 물론 윈텔이 자신들에게 이익이 되도록 하기 위해서 현재의 방향이 좋다고 판단한 것이지만, 다르게 판단하고 행동할 수도 있었기 때문입니다. 예전에 IBM이 그랬듯이 말입니다.
나비효과에 대한 언급도 그러한 맥락에서 이루어진 듯 합니다. 과거의 상황이 MS와 intel이 필연적으로 그렇게 전략을 짜고 행동할 수밖에 없었던 상황인지, 아니면 사용자가 더 큰 불편을 감수해야 하는 다른 수많은 선택이 있었는지... 상황 자체만으로 '저절로' 현재와 같은 PC 환경이 만들어진다는 듯한 말씀을 비유하신 것 같습니다.
가장 첫 머리에 동감합니다. 역사를 분석함에 있어서, 가장 오류에
가장 첫 머리에 동감합니다.
역사를 분석함에 있어서, 가장 오류에 빠지기 쉬운 점이
'현재의 승자가 현자이다' 라는 관점이라고 생각합니다.
위의 분께서는 그런 관점으로 모든 이야기를 해석하시는 군요.
어느날 미법정에서 MS분사 명령후에 MS가 분사된다면, 해석의 관점이
많이 바뀔것 같네요.
과거 AT&T 처럼요.
현자가 단지 승리자라고 해서 비판받을 필요는 없다고 봅니다.그리고
현자가 단지 승리자라고 해서 비판받을 필요는 없다고 봅니다.
그리고 대개 승자라서 현자가 아니라, 현자이어서 승리를 한 것이겠지요. 확률적으로 봐도 그렇고 역사적으로 봐도 그러합니다.
중세 암흑기의 원인으로 비판받는 제국주의 로마가 하루 아침에 제국이 된 것도 아니고 그들의 제국이 아루 아침에 망한 것도 아닙니다. 카르타고와의 전쟁, 갈리아와의 전쟁에서 보여준 그들은 정치적, 군사적 지혜는 그들의 승리할만한 충분한 이유가 있음을 알려주지요. 역사가들은 단지 그들이 써놓은 기록만 본다거나 단지 그들이 승자이어서 로마의 가치를 높게 평가하는 것이 아닙니다. 해상 제국 카르타고를 완파한 로마의 저력을 아마 알게 된다면 새삼 놀랄 것입니다.
뭐 이런 소리해봤자. 로마는 당시의 평화로운 질서를 무너 뜨리고 모든 나라의 헤게모니를 장악할려고 했던 전형적인 군국주의 나라였다고 말하는 사람 분명히 있죠. 뭐 분명 맞는 말이기는 합니다. 헌데 그런게 역사죠.
아무일없이 단지 평화롭게만 지냈다면 글쎄 오늘날의 문명이 가능했을지.
요즘은 1950년대 냉전 시대부터 미국이 로마를 흉내내고 있죠. 힘에 의한 헤게모니 장악은 옛날이나 지금이나 변함이 없군요.
미국이라는 나라 역사는 짧지만 기간이 짧아도 하루 아침에 그렇게 강대국이 된건 아니죠.
로마가 일단 이탈리아 반도를 통일하고 그 다음 카르타고 깨고, 지중해 차지하고, 말안듣는 갈리아 무짜르고, 뭐 이런 과정인데, 미국도 일단 남북전쟁 거치고, 독일 깨고, 일본 깨고, 소련 붕괴시키고. 그리고 그 다음은 말안듣는 아프가니스탄, 이라크...
당시 라틴어가 유럽+북아프리카의 공용어가 되었듯이 요즘은 영어가 전세계 공용어가 되었죠. 한국에서도 토익 600안되면 취직이 불가능하고, 진급할려면 750은 넘어야하죠. 요즘 왜 영어를 해야하나 이런 불만 가지는 사람이 몇 안되죠. 일단 세상이 그렇게 되었으니 영어를 할 수 밖에 없다라는걸 인식하고 있죠.
뭐 암튼 "현자이어야 승자가 될 수 있다"라는 그런 말이었습니다.
바보같은 자는 절대 승자가 될 수 없으며 혹시 일시적으로 승자가 되더라도 곧 무너지게되어 있다라는 그런 말입니다.
주제와는 관계없지만 그리스/로마사는 개인적 관심분야라 말씀드리지만 "중세
주제와는 관계없지만 그리스/로마사는 개인적 관심분야라 말씀드리지만 "중세 암흑기의 원인으로 비판받는 제국주의 로마" 라는 부분은 좀 어폐가 있는 것 같군요. :)
말씀하신 내용은 저도 90%이상 동의합니다. 단지 썬이나 자바에 대한 반
말씀하신 내용은 저도 90%이상 동의합니다. 단지 썬이나 자바에 대한 반감은 모노 프로젝트에 대한 토론과는 직접적인 연관이 없을 뿐이지요 :)
썬의 마케팅 분야에서의 삽질은 유명하지 않나요? 지금도 자바로 돈버는 건 IBM, Oracle, BEA 등입니다. 의도야 어떻든 항상 재주는 Sun이 넘고 돈은 다른 쪽이 챙기지요... MS는 제품을 팔지만 썬은 스펙을 만듭니다. 정확하게는 제품도 팔아보려고 여러번 애를 썼지만 JavaWebServer나 iPlanet등으로 번번히 죽을 쒔지요 :)
국내나 외국의 자바 커뮤니티를 봐도 개발자들이 썬에 대해 호감이나 충성심(?)을 갖는 경우는 거의 없습니다. 오히려 아파치 그룹이나 몇몇 유명 오픈소스 프로젝트가 높은 평가를 받는 경우가 많습니다.
어쨌든 더 이상 이 주제가 "닷넷vs자바"나 "썬vsMS"로 흘러가지 않았으면 합니다.
(저도 lamp 아님)아마 lamp인가 하는 사람의 글을 읽어보시는
(저도 lamp 아님)
아마 lamp인가 하는 사람의 글을 읽어보시는 것이 좋을 것 같네요.
그분이 파악한 바로는 썬의 삽질은 미래의 수익을 위한 투자정도로 생각하는 것 같은데 그 점을 애써 외면하면서 별로 수익도 안되는 분야에(미래의 수익에 비해 상대적으로) 연연하는 것은 잘못된 것 같습니다.
저같이 객관적으로 양자를 보려는 입장에서는 당신의 글은 너무 편향적인 것 같다는 느낌입니다.(솔직하게 쓴 것입니다.)
lamp님...우습지도 않군요. 이런 유치한 짓까지 하시다니... 이 글
lamp님...우습지도 않군요. 이런 유치한 짓까지 하시다니... 이 글이 올라온 IP address가 211.49.109.47이고, 당신이 올린 글이 모두 같은 IP address인 것으로 나와 있는데 왜 다른 사람인 척 글을 올리시나요. 혹시 lamp님과 같은 집에 사는 다른 사람이신가요?
--
WTFM :-)
그런 중요한-_-a 것을 가르쳐 주시면 안되죠.... 이제 lamp님은
그런 중요한-_-a 것을 가르쳐 주시면 안되죠.... 이제 lamp님은 자리를 옮겨 가면서 글을 써야 한다는 것까지 알게 되었습니다. T_T
하 정말 어이가 없네요. 내가 그 유명인사라구요.일 끝내고 들어와
하 정말 어이가 없네요.
내가 그 유명인사라구요.
일 끝내고 들어와 보니 별 황당한 이야기를 다 듣네.
나 lamp라는 사람 좀 되어 보았으면 좋겠군요.
그 사람 홈피 주소가 있어서 가보니 아주 괜챦던데
어쨌든 감사합니다.
절 lamp씩이나 쳐 주셔서
그러고 보니 권순선씨 아주 멋진 것 같애^^
아참 그사람 아이피 막히지 않았나?
그럼 아이피나 풀어 놓고 한번 누가 누군지 살펴봅시다.
허허..
그리고 방금 제 아이피 확인해보니 211.243.55.91입니다. 이런거
그리고 방금 제 아이피 확인해보니 211.243.55.91입니다. 이런거 공개해도 되나?
멋져요 -_-=b
멋져요 -_-=b
제 글이 편향적이라고 생각하신다면 어쩔 수 없지만, 어떤 부분이 그런 지
제 글이 편향적이라고 생각하신다면 어쩔 수 없지만, 어떤 부분이 그런 지는 님의 글만 보고는 판단하기 어렵군요.
(1) 저도 썬 안좋아합니다. 무슨 제가 썬의 옹호자인 양 보였나요?
(2) 닷넷 대신에 자바쓰라는 말한 적도 없습니다.
(3) 누차 이야기했지만 저는 MSvsSun으로 주제를 끌고 나갈 생각은 없습니다.
lamp의 글을 읽어보라고 하셨는데, 자바와 티끌만큼이라도 관계가 있는 주제가 나오면 덮어놓고 자바와 썬을 비방하는 사람이 lamp입니다.
제 글에서 J2EE와 닷넷을 비교한 건 단일 언어/오픈 플랫폼인 J2EE와 다중언어를 지원하지만 사실상 단일한 프레임워크와 벤더를 지닌 닷넷을 비교해서 개발 방법의 획일화는 위험하다는 주장을 뒷받침하려 했을 뿐입니다.
J2EE가 닷넷보다 좋으니 닷넷 대신 자바를 쓰라는 주장이 아니니 오해 없으셨으면 좋겠군요.
왜 남의 나라 회사에서 만든 걸로 우리끼리 싸우는 걸까?우리는 제 3
왜 남의 나라 회사에서 만든 걸로 우리끼리 싸우는 걸까?
우리는 제 3자의 입장에서 공평하게 바라보면 여러가지 면에서 객관적인 결론이 나올 수 있을 것 같은데 모두가 상대는 잘 모르면서 내것만 최고라고 주장하는 것 같아 씁쓸하네
모두가 투자한 시간과 노력이 있기 때문에 그것을 포기하기 어려운 것이랍니
모두가 투자한 시간과 노력이 있기 때문에 그것을 포기하기 어려운 것이랍니다.
사람들이 처음에 자바의 개념이 나와서 실체가 공개되었을때 환호를 하며 달려들었지만 통일성 호환을 보장한다며 썬사가 JCP를 점령했을 때 사람들은 왠지 모를 두려움을 갖기 시작했습니다. VM을 아무나 만들 수 있으리라던 생각은 MS와의 소송에서 완전히 거짓이라는 것으로 드러났고 결국은 새로운 기술을 통한 미래시장의 장악의도를 사용자들은 감지하게 되었습니다.
MS사는 썬의 정책을 정확히 간파하여 미래의 변화된 시장상황에서 살아남기 위해 운영체제시장의 독점체제를 잃어버릴지 모르는 위험을 무릅쓰고 닷넷이라는 개념을 만들어 내게 되었습니다. 사실 사용되는 기술이 자바의 개량형같다는 느낌이 들어서 자바 개발자들에게 많은 비판을 받지만 자바도 마찬가지로 C나 C++의 기술이 발전적으로 접목된 것이니 설득력이 없습니다.
자바 개발자가 C#이나 닷넷을 공격할 이유는 그 어디에도 없습니다.
본인들이 더욱 노력하여 자바 기술이 살아 남도록 노력하면 되는 것이고 기족의 개발자들이 닷넷으로 이전되는 것을 막는 것은 지나친 간섭이라는 판단이 드네요.
얼마전에 SCJP취득 통계를 보니 유독 우리나라에서만 지나치게 자바가 활개를 치고 있는 것 같네요.
그분들 앞날이 걱정되네
닷넷이 유망해 보이면 자신이 더욱 노력해서 닷넷을 따라가면 그만이지 다른
닷넷이 유망해 보이면 자신이 더욱 노력해서 닷넷을 따라가면 그만이지 다른 사람들이 자바가 좋다고 말하는 것까지 막으려는 것은 지나친 간섭이라는 판단이 드네요.
여기 있는 분들이 닷넷을 사용하지 못하게 금지하기라도 했습니까? 단지 그에 대한 자신의 견해를 말하는 것에 불과합니다. 이것을 자기 마음에 들지 않는다고 간섭하지 말라느니 어쩌느니 하는 것은 이 곳의 존재의의를 부정하는 것 이외에 아무런 의미가 없습니다.
자바와 조금이라도 관련된 토론이면 끼어들어 맹목적으로 비난을 퍼붓는 사람
자바와 조금이라도 관련된 토론이면 끼어들어 맹목적으로 비난을 퍼붓는 사람이 한 명 있습니다. 주제가 무엇이든 상대방의 논점이 무엇이든 끝까지 물고 늘어지면서 "닷넷천국 자바지옥"을 외치고 다닙니다.
차분하고 유익한 토론이 될 수 있는 주제를 저런 미꾸라지 한 마리 때문에 망쳐버리는 일이 빈번해서 안타까울 뿐입니다.
닷넷에 대해 부정적 인식을 심어주면서 초보개발자에게 선택의 판단을 어렵게
닷넷에 대해 부정적 인식을 심어주면서 초보개발자에게 선택의 판단을 어렵게 하고 있쟎아!
썬이 JCP를 점령했다는 표현은 어떤 사실을 두고 말씀하신 건지 모르겠군
썬이 JCP를 점령했다는 표현은 어떤 사실을 두고 말씀하신 건지 모르겠군요.
MSJVM과 관련한 소송에 대해선 완전히 오해를 하고 계신 듯 합니다. 자바가 GPL 저작권이 아닌 JCP에 의해 통제되는 것은
(1) 호환성 없는 JVM의 난립
(2) 플랫폼 독립성의 훼손
이렇게 두 가지의 문제를 막기 위한 조치입니다. MS 윈도우즈나 IIS는 MS만 만들지만 J2EE 어플리케이션 서버 벤더는 수십가지 입니다. 만일 웹로직 개발자가 웹스피어나 오라클에서 개발을 할 수 없다면 자바 커뮤니티 전체에 대해서 손해라고 생각할 수 밖에 없습니다.
또한 MS처럼 라이선스를 위반하고 자바 언어 자체를 윈도우즈 전용으로 만들어버리려는 시도도 위험하기는 마찬가지 입니다.
MS가 Sun의 정책을 간파하고 독점 시장을 잃어버릴 위험을 무릅쓰고 닷넷을 만들었다라는 주장은, 글쎄요... 굳이 반박할 필요 조차 못느끼겠군요.
그게 그소리 당신은 앵무세인가.스펙이라는 거 누가 정하나?그리고
그게 그소리 당신은 앵무세인가.
스펙이라는 거 누가 정하나?
그리고 다른 곳에서 만든 VM은 썬에서 만든 코드 한줄도 안쓰나?
한마디로 썬이 만만한 놈들 꿰차고 대장노릇하는 것 아닌가?
MS에서 스펙을 제출하여 썬이 수용하면 그런 소송 필요없지 안그래?
그런데 썬이 수용했을리 없고 그런 이유는 JCP의 주도권 문제 아닌가?
그럼 당신 같으면 어떻게 대응할까?
나같으면 MS같이 자바의 발전형을 만들어서 썬사 죽쑤게 만들겠다.
한마디로 VM에 통제권을 독점적으로 고수하려 한 썬이 결국은 제 무덤을 판 것이지!
MS에서 스펙을 제출하여 썬이 수용하면 그런 소송 필요없지 안그래?
MS에서 스펙을 제출하여 썬이 수용하면 그런 소송 필요없지 안그래?
말씀에서 의미 하셨듯이, MS에서는 스펙을 제출하지도 않았지요.
너무 독단적인 말씀과 과격한 표현이 거슬리는 군요.
재미있는 사실 하나는 Java로 돈을 제일 많이 버는 업체는
Sun이 아닌 IBM입니다.
그랬나요?저는 금시초문인데그리고 썬사는 MS의 아성을 깨는데 IB
그랬나요?
저는 금시초문인데
그리고 썬사는 MS의 아성을 깨는데 IBM을 우군으로 인식하고 있습니다.
주도권이 유지된다면 푼돈버는거야 뭔 상관인가?
최근 수년간 시장 상황에 대해 별로 친숙하지 않으신 듯 합니다. 현재 자
최근 수년간 시장 상황에 대해 별로 친숙하지 않으신 듯 합니다. 현재 자바의 가장 큰 옹호자는 IBM이고 사실 자바 뿐 아니라 '오픈소스의 수호자' 쯤으로 비쳐지기를 바라는 눈치입니다. 그렇다고 IBM이 MS와 적대 관계는 아닙니다. 특히 웹서비스 쪽에서는 협력적이지요...
그게 뭔 상관이데요?설명좀 해보슈!내가 하는 말과 무슨관계가
그게 뭔 상관이데요?
설명좀 해보슈!
내가 하는 말과 무슨관계가 있다는 것인지?
정말 말하는투가 재수 없네요. 제발 여기서 꺼져버려주세요.자바로
정말 말하는투가 재수 없네요. 제발 여기서 꺼져버려주세요.
자바로 IBM이 이익을 더 보고.. 더 기술력이 뛰어난게 IBM이라는건
많은 사람들이 알고 있죠.
부탁입니다. 꺼져버려.
알지도 못하는 문제에 목청만 높이는 건 토론자의 자세가 아닙니다. 최소한
알지도 못하는 문제에 목청만 높이는 건 토론자의 자세가 아닙니다. 최소한 JCP가 무엇인지 개요라도 파악하고 글을 올리시기 바랍니다.
본질이 중요하지 껍데기가 중요한가?
본질이 중요하지 껍데기가 중요한가?
님한테는 모든 자바 관련 토론의 본질이 다른 사람들에게 썬과 자바의 사악
님한테는 모든 자바 관련 토론의 본질이 다른 사람들에게 썬과 자바의 사악함을 널리 홍보하는 건지 모르겠지만, 최소한 자바의 라이선스 정책을 비판하는데 JCP가 뭔지를 모른다면 '본질을 모른다'라는 소리를 들어도 할말이 없습니다.
(그나저나 왜 모노를 이야기하는데 자바에 대한 비난이 끼어드는지 모르겠군요)
이곳에서 모노에 대해 이야기하는데 모노의 장래를 부정적으로 인식시키려하며
이곳에서 모노에 대해 이야기하는데 모노의 장래를 부정적으로 인식시키려하며 MS와의 연관성을 부각시키는 사람들은 자바옹호자들인 것 같은데.
그리고 뭐가 본질인지 눈좀 크게 뜨시고 보세요
모노에 대해 토론하는데 모노의 장래를 부정적으로 말하면 안된다? 그럼 여
모노에 대해 토론하는데 모노의 장래를 부정적으로 말하면 안된다? 그럼 여긴 모노 찬양 게시판입니까?
문제는 부정적 인식이 유독 자바개발자들에게서 나온다는 것이지요.그 사
문제는 부정적 인식이 유독 자바개발자들에게서 나온다는 것이지요.
그 사람들이 닷넷개발자인가? 아니쟎소.
도대체 뭘 안다고 그렇게 부정적인가?
음, .net은 j2ee와 상당히 유사하고 j2ee에서 좀 복잡했거나 아
음, .net은 j2ee와 상당히 유사하고 j2ee에서 좀 복잡했거나 아쉬웠던 점들이 보완된 것도 꽤있습니다. 어디까지나 제 관점에서 :)
제 생각엔 MS 개발자보단(vb 개발자가 .net vb를 배우는 거보단) j2ee에 있는 java 개발자가 .net에 더 잘 적응하고 .net이 요구하는 바를 잘 충족하리라고 봅니다.
그럼에도 불구하고 제가 .net에 대해서 부정적인 이유는 첫째 시장에 나오지도 않은 놈이 너무 시끄럽다. 저는 같은 이유로 sun의 지니에도 부정적이므로 sun의 주구로 치부하지 말기를. 이제 겨우 개발툴이 나오기 시작하고 있는 놈이 마치 완성된 product인거 처럼 프로모션하는데 당연히 그걸 사용해서 프로젝트를 해야하느야 마느냐를 결정하는 입장에선 투자자나 경영진의 눈을 속이는 마케팅이 짜증 납니다. 뭐 이건 몇달 전 상황이었으니 지금은 또 모르겠군요.
그 담은 MS의 전력입니다. Windows가 나올때 MS에서 한말이 여태까지는 패키지 소프트웨어 회사들이 시스템영역까지 손대야 하느라고 수고가 많았다. 하지만 이젠 윈도우즈 api를 쓰면 니들 전문영역만 신경써도 된다고 해놓고. 결과는 패키지 소프트웨어의 멸종으로 나타났죠. 당장 기억나는게 플로팅 툴바군요. api로는 없는데 갑자기 오피스에서였나? ㅤㄸㅣㄱ 나타나더니만 한 반년뒤인가에 api에 추가됐었나. 그리고 연결하면 사용자 정보 죄다 긁어서 퍼올리던 MSN(윈도우즈95에 있던 인터넷을 대체하겠다던 그거) 뭐 이따우 짓들을 볼때 도덕적으로 신뢰할 수 없는 회사라서 부정적입니다.
.net에 대해서 부정적인건 기술적인 요인이라기 보다는 정치적(?)인 요인이 다분한것 같군요. 그리고 그 근거는 공인된 MS의 과거 행적에 의한 것이고.
기술적으로는 .net이 보안 부분의 hole이 생기기 쉽다는 견해가 많이 대두되고 있고 이역시 다른 os나 서버사이드 업체에 비해 상대적으로 보안문제에 관대한 혹은 은폐하는 MS의 과거 행적으로 봤을때 심각하지만 제가 확인해 드릴 수 없는 분야이므로 주장하지는 않겠습니다.
독점지향적이고 마케팅이 드라이브하는 MS의 전략과 자유소프트웨어 공동체라 참 잘맞는 궁합일 것 같군요.
우습네요. 당신은 자바 잘합니까?
우습네요. 당신은 자바 잘합니까?
저는 과거부터 지금끼지 자바의 기술적인 면에 대해서 언급한 적이 단 한번
저는 과거부터 지금끼지 자바의 기술적인 면에 대해서 언급한 적이 단 한번도 없습니다.
그래서 자바보고 뭐라하우?
그래서 자바보고 뭐라하우?
> 더구나 서버 프로그램을 개발할 때 외주 인력이 Cobol.NET, C
> 더구나 서버 프로그램을 개발할 때 외주 인력이 Cobol.NET, C#.NET, VB.NET 한 명씩 참여한다고 가정하면 유지보수의 어려움은 쉽게 짐작할 수 있습니다.
- 바이너리 레벨의 컴포넌트들을 결합하는 것이라면 해당 컴포넌트에서 버그가 발견되기전까지 해당 컴포넌트 개발자는 필요없을 듯합니다. 즉 늘 모든 개발자가 죽치고 앉아있을 상황은 나오지 않을 듯 보입니다. 예를 들어 A라는 개발자가 Visual C++로 컴포넌트를 만들었고 B라는 개발자가 Visual Basic으로 그 컴포넌트를 가지고 프로그래밍 한다고 할때 B가 작업하는 동안 A가 죽치고 앉아 있지 않습니다. 이 경우와 마찬가지 아니겠습니까? 컴포넌트에서 버그가 발견되었다고 해도 B는 자신의 코드는 고칠 필요가 없고 A가 해당 컴포넌트의 버그를 수정해 주면 됩니다. 안 그렇습니까?
실질적으로 컴포넌트 기반 프로그래밍에서 컴포넌트의 대부분은 외주제작아닙니까?
> 중요한 것은 만일 리눅스와 윈도우즈 모두 닷넷으로 통합된다면 이러한 패러다임 자체의 선택 가능성이 사라진다는 것을 뜻합니다.
- 패러다임이 사라지지는 않습니다.
> JCP의 통제를 받는 자바를 오픈소스라고 생각하지 않는 사람들은 어차피 닷넷이 표준화 기구에 제출된 규약이기 때문에 MS의 마음대로 움직이지 않을 거라 믿습니다. 하지만 처음부터 JCP의 취지는 썬의 독점력 유지가 아닌 자바 플랫폼의 호환성을 지키려는 것이었습니다. 즉, 설사 모노가 MS와 독립적으로 닷넷 플랫폼을 발전 시킬 수 있다고 해도 윈도우즈에서 사용되는 닷넷과 호환되지 않는다면 본문에서 내세운 플랫폼 호환이나 개발비용 절감 등의 장점은 사라집니다.
- 취지가 어떻든간에 실질적으로 JCP는 SUN의 위치를 확고하게 보장해 줍니다. 그리고 개발비용은 절감됩니다. 절감된다는 말이 비용이 완전히 상쇄된다는 말이 아닙니다. 절감은 됩니다. 님은 계속 프레임워크를 문제시하고 있는데 그 말을 그대로 사용하면 동일한(호환이 되는) 프레임워크만큼 비용이 절감됩니다. 바이너리 호환은 당연히 되겠으니...
......
> 저는 J2EE 프로그래머지만 만일 C#이나 C++로 EJB/J2EE를 구현해야 한다면 - 또 그게 가능 하다면 - 새로운 문법을 익힐 의향이 있습니다. 하지만 무조건 데이터베이스 접근은 ADO.NET으로, 서버 페이지는 ASP.NET으로, GUI는 윈폼으로 하는 식의 프로그램은 하고 싶지 않습니다.
개인적으로 개발 언어 자체 보다는 프레임워크, 패러다임의 독점이 더 무섭게 느껴지는 군요...
- 모노에서는 GTK를 사용하는 모습을 볼 수 있습니다. 이게 무엇을 뜻하겠습니까? 필요한 컴포넌트는 만들어서 쓰면 됩니다. 충분히 만들 수 있습니다. 그리고 컴포넌트 모아놓으면 프레임워크가 되겠지요. 그리고 그 컴포넌트 자체를 멀티플래폼으로 만들면 충분히 그걸 사용하는 프로그램도 멀티플랫폼으로 돌아갑니다. GTK를 윈도우용으로 포팅하고 .NET에 바인딩하면 충분히 가능할 것입니다. 님의 발언은 마치 ".NET은 include나 import가 없다. 그래서 .NET안에 있는 것만 써야된다."라는 소리로 들릴 지경입니다.
그럼...
일리 있는 지적입니다. 하지만 부분적으로 제 생각과 차이가 나는 부분이
일리 있는 지적입니다. 하지만 부분적으로 제 생각과 차이가 나는 부분이 있습니다.
우선 유지보수 가능성에 대한 부분은, IT업체의 특성상 이직률이 많다는 현실을 무시할 수 없습니다. 가장 이상적인 경우는 표준적 프레임워크를 사용하고 산출물만 잘 관리하면 어느 개발자가 새로와도 전임자의 코드를 유지보수 할 수 있어야 하지만 다중언어 지원의 경우 문제가 될 수 있습니다. 코볼 은 극단적인 예지만 상대적으로 인력을 구하기 쉬운 언어와 그렇지 못한 언어의 차이는 분명 존재합니다.
> > 중요한 것은 만일 리눅스와 윈도우즈 모두 닷넷으로 통합된다면 이러한 패러다임 자체의 선택 가능성이 사라진다는 것을 뜻합니다.
>
> - 패러다임이 사라지지는 않습니다.
그럴까요? 여러번 언급한 스펙과 구현의 차이점 때문에 특히 서버측 자바 플랫폼의 경우 특정 벤더에 종속적이지 않지만 닷넷은 분명 MS가 정하는 방향을 따라갈 수 밖에 없다고 생각합니다. (아래 오피스의 예를 참조하세요)
그런 상황에서 MS와 같이 독점력을 지닌 기업이 사용하는 프레임워크를 카피해서 리눅스의 표준으로 삼는건 상당히 위험하다고 봅니다.
쉽게 말해 리눅스에서 익스플로러와 MS오피스가 돌아가는 상황이 결코 리눅스와 오픈소스 커뮤니티에 긍정적으로 작용하지 않을 것이란 뜻입니다. 개발 프레임워크 쪽에서도 상황은 마찬가지 아닐까요?
> - 취지가 어떻든간에 실질적으로 JCP는 SUN의 위치를 확고하게 보장해 줍니다. 그리고 개발비용은 절감됩니다. 절감된다는 말이 비용이 완전히 상쇄된다는 말이 아닙니다. 절감은 됩니다. 님은 계속 프레임워크를 문제시하고 있는데 그 말을 그대로 사용하면 동일한(호환이 되는) 프레임워크만큼 비용이 절감됩니다. 바이너리 호환은 당연히 되겠으니...
죄송하지만 이 부분은 논점을 잘 이해하지 못하겠습니다. 좀 더 자세히 설명해 주셨으면 좋겠군요...
> - 모노에서는 GTK를 사용하는 모습을 볼 수 있습니다. 이게 무엇을 뜻하겠습니까? 필요한 컴포넌트는 만들어서 쓰면 됩니다. 충분히 만들 수 있습니다. 그리고 컴포넌트 모아놓으면 프레임워크가 되겠지요. 그리고 그 컴포넌트 자체를 멀티플래폼으로 만들면 충분히 그걸 사용하는 프로그램도 멀티플랫폼으로 돌아갑니다. GTK를 윈도우용으로 포팅하고 .NET에 바인딩하면 충분히 가능할 것입니다. 님의 발언은 마치 ".NET은 include나 import가 없다. 그래서 .NET안에 있는 것만 써야된다."라는 소리로 들릴 지경입니다.
아래서 지적했듯이 클라이언트 프로그램의 멀티플랫폼 개발은 그렇게 단순하지 않습니다. 각각의 플랫폼에서 네이티브 위젯을 사용하는 전략은 최초의 자바 GUI툴킷인 AWT가 이미 시도했지만 실패했습니다. 반대로 GTK를 윈도우즈에 포팅하는 방식은 스윙의 접근 방식이었지만 아시는 바대로 결과는 좋지 못합니다. 물론 같은 방법으로도 능력에 따라 결과가 차이 나겠지만 근본적인 문제점 - 즉, 전자의 경우 컴포넌트 확장의 어려움, 빈약한 컴포넌트 종류와 후자의 경우 네이티브 어플리케이션에 대해 상대적인 사용성의 문제나 성능이 문제가 될 수밖에 없습니다.
필요한 컴포넌트는 만들어 쓰면 된다고 하셨는데, 추상화된 컴포넌트 계층 아래 실제 네이티브 위젯이 들어있다면 쉬운문제가 아닙니다. 예를들어 닷넷이 지원하는 텍스트 영역 컴포넌트가 윈도우즈에서 MFC, 리눅스에서 GTK의 상응하는 컴포넌트를 쓴다면, 이를 확장해서 HTML이나 컬러링을 지원하게 하는 건 거의 불가능에 가깝습니다.
님의 글을 읽어보면마치 Java의 classpath(용어가 적당할지
님의 글을 읽어보면
마치 Java의 classpath(용어가 적당할지 모르겠군요)같은 것의 Mono에서의 완전한 구현을
문제시하는 것 같습니다.
만약 그렇다면 저는 개인적인 입장으로 "전혀 그럴 수 없다."라고 답해야 할 것이라고 생각됩니다.
표준화 기구에서 관리하겠다는 것은
C#이라는 언어스펙과 런타임구조정도 뿐입니다.
.NET과 같은 프레임워크 자체에 대한 언급은 제가 알기로 없습니다.
즉 멀티 플랫폼을 위한 런타임과(Java의 jvm정도) 그걸 사용할 수 있는 언어스펙을 표준화했을뿐 .NET 프레임워크를 공개하겠다고 한적은 없는 것으로 알고 있습니다.
그러니 그 부분에 관한 문제였다면 님과 의견이 같습니다.
그런데 위 기사에서 얘기하고 있는 것은 제가 볼때 다른 얘기 같습니다.
- 윈도우 개발자들은 리눅스를 위한 코드를 작성할 수 있다.
: 이 문장은 모든 .NET프로그램이 리눅스에서 돌아갈 수 있다는 말이 아니죠.
- 개발자들을 윈도우 세계에서 리눅스 플랫폼으로 이끌어오는 것이 쉬워진다.
: 이 문장은 아무런 전환(교육)없이 하루아침에 당장 바뀐다는 말이 아니죠.
또한 그들에게 리눅스를 사용하게 만든다는 말로도 보이지 않습니다.
단지 그들이 만든 프로그램이 리눅스에서도 돌아가게 하는 것이 쉬워진다는 의미로 보아집니다.
제가 볼때 ASP.NET이나 ADO.NET같은 것은 리눅스에서 나올 수 없다고 봅니다.
나오려면 MS에서 만들어 줘야 될 것이라 봅니다.
미구엘은 Gnome개발자이지 리눅스개발자는 아닙니다.
그의 관점에서는 운영체제가 뭐든지 상관 없으리라 봅니다.
HURD던 BSD던 리눅스던 말이죠.
그런 상황에서 Gnome을 Mono를 통해 구현하는 것이 이상적이게 보일 수 있습니다.
그렇게 되면 Windows에서도 기존의 상황 보다는 쉽게 Gnome이 돌아갈 수 있을 것이라 봅니다.
그렇게 되면 Gnome 프레임워크(Gnome.NET)가 구현된 Windows에서
Visual Studio를 사용해서 기존의 Windows개발자들이 Gnome.NET 응용프로그램을 만들 수 있고
이것은 곧 Linux(나 기타 여러운영체제)에도 동시에 해당 응용프로그램 만들어지는 효과가 될 것입니다.
즉 제가 생각하기로는
- 윈도우 개발자들은 리눅스를 위한 코드를 작성할 수 있다.
- 개발자들을 윈도우 세계에서 리눅스 플랫폼으로 이끌어오는 것이 쉬워진다.
라는 것은 그러한 개념의 문제이지
Windows의 ASP.NET이나 ADO.NET까지 Linux에 완전히 포팅하겠다는 얘기로 들리지는 않습니다.
(기본적인 .NET 프레임워크 정도는 기존의 오픈소스 Java기술을 활용해서 어느정도 만들어내겠지만...)
오히려 Gnome.NET을 만드는데 주력해야 되겠지요.
즉 MS의 것에 한정되지 않고 Gnome.NET을 만들어서 쓰면 됩니다.
기존의 Windows진영의 개발자도 Gnome.NET API 정도만 배우면 충분히 Visual Studio를 통해서 만들어 낼 수 있습니다.
위의 기사에서도 그런 의미에서 "다른 말로 하자면, 윈도우 개발자들이 리눅스를 위해 프로그램을 작성하는 것이 쉽다면 그들은 리눅스를 위한 프로그래밍을 할 것이다. 전혀 다른 API를 재교육 받는 것조차 개발자들은 개의치 않을 것이다." 라고 하고 있는 것으로 보아집니다.
Java도 충분히 가능은 한 일이겠으나 AWT얘기도 있는 것으로 알고 있고
그런 문제뿐만 아니라 기존의 Visual Studio를 통한 개발자를 끌어오는 기대효과 또한 거둘 수 없을 것입니다.
JBuilder같은 툴도 이미 리눅스에서 잘 돌아가고 있고 JDK, JRE도 이미 리눅스에서 잘 돌아가고 있으므로
그걸 통해서 충분히 자바 개발자는 리눅스에서 그들의 프로그램을 돌릴 수 있을 것입니다.
황당하군요.. 미구엘이 gnome개발자이지 linux개발자가 아니
황당하군요..
미구엘이 gnome개발자이지 linux개발자가 아니라고요? 허참.. -_-;;
미구엘은 과거 linux kernel의 sparc port 의 핵심개발자였습니다. -_-
그리고 그 후에 gnome 프로젝트를 시작한건데..
한번 그의 홈페이지에 가셔서 그가 해논걸 보시지요..
그는 gnome 관련뿐만 아니라 과거엔 별의 별(?) 방대한 분야의 오픈 소스 프로젝에 엄청난 기여를 한 사람입니다. 특히 linux 쪽에..
지금은 mono에 주로 집중하지만..
정확하지 않은 그런말 햇다간 욕먹기 쉽상입니다.
GNOME stuff
GNOME
Gnumeric Spreadsheet
Mono
Bonobo Component Architecture
GNOME Printing Architecture
Evolution
GNOME Calendar
General GNU stuff
Midnight Commander file manager
Port of the libc 4, 5 to Linux/SPARC; Some GNU Libc 6 work.
Linux stuff
Linux on the SPARC
Linux Software RAID
Linux on the SGI
홈페이지에서 갖고 온겁니다. 그가 현재 하는중이고 과거 해왔던일들 입니다.
밑에 보면 스팍과 소프트웨어 RAID, SGI 쪽 개발까지 커버하고 있습니다. -_-;
참, 대단한 사람이죠.
저렇게 넓은 분야는 알기도 힘들고 손대기조차 어려울텐데 직접 개발까지 했다니.. 보통 사람은 한쪽도 이해하기가 힘든데..
아마 외계인일꺼야 분명..
당.. 당신.. 이 인간이야? T_T
http://primates.ximian.com/~miguel/
지금하고 있는 일에 대해 얘기하고 있는 것이지과거의 일을 얘기하는 것
지금하고 있는 일에 대해 얘기하고 있는 것이지
과거의 일을 얘기하는 것입니까?
그가 뭘하던 그건 그의 자유니 앞으로 어떻게 될지는 모르겠으나
쉽게 말하면 지금은 Linux커널 개발에서 손땠습니다.
즉 Linux커널 개발자가 아닙니다.
비유가 쩜 이상하기는 하지만 쉬운 예를 위해서 들면
과거에 도둑질한 적이 있는데
지금은 마음을 바로잡고 손을 땐 사람에게
"그래도 넌 도둑놈이야."라고 그럴까요?
즉 님이 지적한 표현은 아무 문제 없어 보입니다.
수정이 안되는 관계로 따로 적습니다.(수정해서 윗글 밑에 추가하고 싶
수정이 안되는 관계로 따로 적습니다.
(수정해서 윗글 밑에 추가하고 싶지만... -_-;;;)
물론 적기로는
"리눅스 개발자의 입장이 아니라 그놈 개발자의 입장에서 볼때"
정도의 의미로 적은 것인데
그것이 과거의 행적까지도 오해하게 만들 소지가 있다면
물론 문제가 있는 표현이기는 하겠군요.
플랫폼 구현에 대한 부분은 공감대가 형성된 것 같군요.모노의 AS
플랫폼 구현에 대한 부분은 공감대가 형성된 것 같군요.
모노의 ASP.NET이나 ADO.NET 구현에 대한 계획은 있습니다.
http://go-mono.com/asp-net.html
http://go-mono.com/ado-net.html
http://go-mono.com/winforms.html
이런 방향으로 볼 때 모노는 거의 윈도우즈 닷넷의 클론을 지향하는
것이 아닌가 싶기도 하군요.
GNOME.NET이 나온다면 이미 그놈 데스크탑에서의 개발 프레임워크는
닷넷으로 통합됩니다. 개인적으로 C#이 C/C++/자바/Perl과 같은
수준으로 그놈이나 GTK 바인딩을 가지는 건 몰라도 '그놈을 개발하려면
닷넷을 하라'는 식은 지양했으면 합니다. 사실 이 부분에 대해선 논란
이 많은 것 같더군요.
그놈이 리눅스에서 차지하는 비중을 볼 때 이런 상황이 현실이 되면
윈도우즈와 리눅스에서 클라이언트 프로그램은 모두 닷넷으로 짤 수밖에
없습니다. 제가 우려하는 바는 바로 그런 식의 획일화입니다.
자바와 비교한 부분은 닷넷이 멀티플랫폼 클라이언트 개발에 있어 모든 문제를 해결하지 않을 것이라는 점을 강조한 것입니다.
JBuilder나 Eclipse가 리눅스에서 잘도는 것과 그놈 어플리케이션을 모두 자바로 만드는 건 다른 문제아닐까요? 그래서 플랫폼이 아닌 언어 차원에서 C#/GTK, C#/GNOME 바인딩을 지원하는 것이 올바른 방향이라고 봅니다.
그럼~
위의 글 쓴 사람입니다.가르쳐 준 링크로 글을 몇개 읽어보니 거의 완
위의 글 쓴 사람입니다.
가르쳐 준 링크로 글을 몇개 읽어보니 거의 완전한 포팅으로 향해 가더군요.
근데 제 개인적으로는 왜 그걸 부정적으로 생각해야 하는지 그점에 반대합니다.
오픈소스 프로젝트중에 GNUStep이라고 있습니다.
지금은 거의 완전한 구현에 가깝죠.
그렇다고 OpenStep의 후신이라 할 수 있는 Mac OS X의 Cocoa 응용프로그램을
가져다가 돌리면 너무도 당연하게 안돌아갑니다.
단지 소스레벨에서 큰 수정없이 사용할 수 있을 정도의 장점이죠.
그런데 만약에 Mono에서 그걸 거의 완전히 지원해 준다면
예를 들어 PhotoShop.NET이 나왔을때
리눅스나 프비나 기타 등등의 환경에 모두 무난히 돌아가리라 보아지는군요.
이런 경우가 발생하면 일반사용자들의 입장이라면 환영할 일이지 반대할 일은 아니리라 봅니다.
그걸 부정적으로 보는 입장이라면
자바 개발자의 입장에서 왜 그 역활을 자바가 하지 못하는지에 대한 불만정도는 있을 수 있겠지만...
일반사용자 입장을 생각해 보면 아주 바람직한 방향이라고 봅니다.
사견이지만 그 점(자바)에 관해서는
"Java버젼의 PhotoShop"과 "PhotoShop.NET"
제가 볼때 PhotoShop.NET의 가능성이 더욱 높고
그래서 .NET을 추구하는 것이 더욱 큰 실리를 가져다 줄 것이라 보여지는군요.
즉 .NET을 품어라라는 기사가 지향하는 것은 바람직 한 것이라 봅니다.
자바를 들먹거리며 방해하는 일은 없기를 바랍니다.
자바 개발환경은 윈도우에도 이미 잘 나와있고
리눅스 쪽에도 이미 잘 나와있습니다.
즉 Java버젼의 PhotoShop같은게 나와도 아무문제 없이 돌릴 수 있을텐데...
왜 자바가 이 문제에 끼여들어야 되는지 의문입니다.
저도 왜 자바 문제가 끼어드는지 의문입니다 :)사실 제가 서버측에
저도 왜 자바 문제가 끼어드는지 의문입니다 :)
사실 제가 서버측에서 프레임워크로서의 닷넷과 J2EE를 비교해서 말하는 과정에서 일부에 의해 "자바vs닷넷"으로 논점이 바뀌어 버렸군요.
제가 말하고 싶은 건 닷넷으로 하려하는 걸 자바로 하자는 건 아닙니다.
단지 지금까지의 MS의 행태를 볼 때 MS의 플랫폼을 포팅해서 리눅스나 그놈의 표준으로 삼으려는 시도가 위험하다는 것을 지적하고 싶을 뿐입니다.
Photoshop.NET으로 다시 설명을 드리자면, 우선 모노의 닷넷 포팅으로 리눅스 사용자들도 포토샵을 사용할 수 있게 됩니다. 그러다보면 일반 사용자들도 하나 둘씩 김프 같은 경쟁관계에 있는 오픈소스 프로그램에서 기존 윈도우즈 기반의 유명 프로그램으로 옮겨갈 확률이 높습니다. (익스플로러, 오피스, 미디어 플레이어 등이 리눅스에서 돈다면 이해하기 쉬울 것 같습니다)
그러면 MS는 차기 버전 닷넷에 J++이나 익스플로러 등에서와 같이 원래의 표준에 확장기능을 추가해 갑니다. 이제까지 경험한 바로는 개발자들이나 사용자들은 편리함에 끌리거나 원래의 표준 스펙과 MS의 확장 기능을 구분하지 못해 점차 MS에 종속적인 닷넷 플랫폼 전용 프로그램을 만들고 사용하게 됩니다. (현재 모질라에서 자바스크립트 에러가 발생하는 페이지들은 바로 99% 이러한 이유로 생긴 것입니다 - ECMA와 JScript, 그리고 Javascript의 차이를 아는 웹디자이너는 드뭅니다)
이 때 확장 기능을 사용하는 포토샵.NET의 차기버전은 당연히 모노가 포팅한 닷넷에서 실행될 수 없습니다. 모노가 닷넷의 포팅을 통해 플랫폼 호환을 목적으로 삼는다면 MS가 확장한 스펙을 따라갈 수밖에 없습니다. 상식적으로 MS가 닷넷을 개발하면서 모노와의 호환을 우선으로 생각하지는 않겠지요.
결국 모노가 MS닷넷을 포팅하는데 치중한다면 MS나 기타 killer어플리케이션을 가진 회사들이 리눅스 사용자들을 시장으로 장악하는데 도움을 주는 역할을 할뿐입니다.
사실 제가 제일 처음에 J2EE와 비교하면서 주장했던 논점은 이러한 문제 보다는 개발 프레임워크의 획일화 였지만, 이 부분에 대해서는 이미 여러번 설명을 드렸기 때문에 반복하지 않겠습니다. 모노의 주요한 목적은 윈도우즈 닷넷용 바이너리를 리눅스에 포팅하는 것은 아니라는 사실은 알고 있습니다.
그럼...
님과 같은 우려때문에 제가 Office.NET이 아니라 Photoshop
님과 같은 우려때문에 제가 Office.NET이 아니라 Photoshop.NET을 예로 들었던 것입니다.
Question 37: Do you fear that Microsoft will change the spec and render Mono useless?
No. Microsoft proved with the CLI and the C# language that it was possible to create a powerful foundation for many languages to inter-operate. We will always have that.
Even if changes happened in the platform which were undocumented, the existing platform would a value on its own.
저도 위의 FAQ에 나오는 답변 내용과 생각이 같습니다.
혹시나 해서 보았더니 역시 제 생각과 같은 내용이 있더군요.
답변의 두번째 단락이 특히나 중요한데...
님이 지적한 MS의 횡포는 "OS간의 바이너리 비호환성"에 기초하고 있습니다.
MS가 스펙을 바꿔서 그 프로그램이 바르게 안돌아가면
그 프로그램이 돌아갈 OS는 지구상에서 멸종되는 겁니다.
그래서 할 수 없이 바뀐 스펙을 따라가거나
비공개스펙이라면 속수무책으로 피를 보고 말겠죠.
당할 수만은 없어 OS를 바꾸는 것을 생각해 볼 수 있으나
이 상황에서 OS를 바꾸는 것은 프로그램 전체를 새로 작성한다와
거의 동일한 수준이라 불가능에 가깝습니다.
그러나 .NET에서는 얘기가 다른 것이 "OS간 바이너리 호환성"을 가지고 있습니다.
Photoshop.NET이 MS의 스펙변화로 제대로 동작하지 않을때 두가지 선택이 가능합니다.
그걸 따라가거나 OS를 바꾸는 것입니다.
Adobe가 따라갈 수 있는(documented) 스펙이라면 Mono도 충분히 따라갈 수 있을 것이고
비공개(undocumented) 스펙이라면 오히려 Mono에서만 돌아가게 될 것입니다.
즉 그러한 스펙따위의 변화는 .NET에서는 오히려 MS에게 자살골로 작용할 것입니다.
닷넷 플랫폼 전체가 표준 기구에 의해 통제되는 건 아니지만, 어쨌거나 O
닷넷 플랫폼 전체가 표준 기구에 의해 통제되는 건 아니지만, 어쨌거나 OS간 바이너리 호환성이 보존되는 것은 어디까지나 원래의 닷넷 스펙만을 사용했을 때문임은 지적하신 바와 같습니다. 이는 마치 JScript와 온갖 IE의 확장 기능만 사용하지 않으면 모질라에서도 최소한 에러 없이 브라우징이 가능한 페이지를 만들 수 있는 것과 같습니다.
하지만 아시는 것처럼 현실은 그렇지 못합니다. 브라우저 시장에서 90% 이상을 선점한 MS가 OS에 끼워파는 IE에 어떤 기능을 추가하건 웹개발자들은 따라갈 수밖에 없습니다. 물론 MS는 IE가 "가장 표준에 충실한 브라우저"라고 계속 선전을 하고, 사실 '가장'이란 말만 빼면 크게 틀린말도 아닙니다. 다만 MS의 독점적 지위와 개발자들의 현실 때문에 결과적으로 비표준적 IE 전용 사이트들이 양산될 따름입니다.
물론 이러한 확장 기능들은 MSDN에 잘 정리되어 있고 원한다면 모질라나 컨쿼러가 못따라갈 이유도 없습니다. 하지만 언제나 따라가는 건 MS가 아닌 힘없는 오픈소스 프로젝트들이라는게 문제이지요...
결국 누구나 자유롭게 사용해야할 인터넷이 MS제품으로 접근하고 개발해야 최적의 결과를 얻을 수 있는 닫힌 공간이 되어버리는 것입니다.
비주얼스튜디오 닷넷만 봐도 MS가 닷넷에서도 동일한 전략을 채택할 의도와 능력을 모두 가지고 있음을 무시할 수 없습니다. 모노는 의도는 순수하지만 이러한 현실에 1:1로 맞서서 독자적인 영역을 확보하는 건 어렵다고 생각합니다.
아차!! ^^ 위의 FAQ는http://go-mono.com/faq.
아차!! ^^ 위의 FAQ는
http://go-mono.com/faq.html#msft
에 나오는 내용이었습니다.
저요. 초자라서 묻는 것인데 당신 닷넷을 잘못이해하시는 것 같애.제가
저요. 초자라서 묻는 것인데 당신 닷넷을 잘못이해하시는 것 같애.
제가 틀리다면 저에게 한수 가르쳐 주시면 되구요.
개발언어는 선택하는 데 상당한 자유가 있는 것으로 알고 있는데 아닌가요.
미구엘이라는 사람이 C#언어에 기반해서 프레임을 만들든 말든 그 하부구조가 표준화 되어 있기 때문에 한층 내려가서 다시 다른 계단으로 올라가면 다양한 언어와 소통이 된다고 들었는데요.
이점이 자바와 다른 점이고 바로 이점 때문에 많은 이종 언어 개발자를 끌어 안는 이점이 있는 것이라 생각하는데요.
문제는 뭐냐면 자바에는 이러한 접근 개념이 없다는 것이 문제지요.
틀렸다면 가르켜 주세요.
제가 잘못이해한 것도 아니고 님께서 잘못 이해하고 계신 것도 아닙니다.
제가 잘못이해한 것도 아니고 님께서 잘못 이해하고 계신 것도 아닙니다.
자바가 플랫폼 독립성을 기치로 내세우는 것 만큼 닷넷 역시 다중언어 지원을 내세우고 있는 것은 사실이고 또 분명 실제로 지원될 것입니다.
다만 저나 대부분의 .NET에 대한 자바측 토론자들이 주장하는 바는 다중언어 지원이 유지보수 측면에서도 별도움이 안되고, 특히 서버측 개발에서는 무엇보다 언어나 문법 보다는 프레임워크가 훨씬 중요하기 때문에 여러 언어로 닷넷 프레임워크를 사용하는 것보다는 자바 언어로 다양한 프레임워크를 사용하는 것이 낫다고 생각하는 것입니다.
사실 이런 부분은 개발자 개개인의 선호의 문제이지만, GNOME.NET에 대한 논의나 MS의 독점 상황을 염두에 두면 좀 더 복잡해지지요...
참고로 자바 자체도 다중언어를 지원합니다만 닷넷 처럼 비중을 두고 있지 않습니다. 최소한 JPython정도는 실용적 수준이라고 생각됩니다.
그럼...
다만 저나 대부분의 .NET에 대한 자바측 토론자들이 주장하는 바는 다중
다만 저나 대부분의 .NET에 대한 자바측 토론자들이 주장하는 바는 다중언어 지원이 유지보수 측면에서도 별도움이 안되고, 특히 서버측 개발에서는 무엇보다 언어나 문법 보다는 프레임워크가 훨씬 중요하기 때문에 여러 언어로 닷넷 프레임워크를 사용하는 것보다는 자바 언어로 다양한 프레임워크를 사용하는 것이 낫다고 생각하는 것입니다.
단지 견해일 뿐이지요. 이런 견해는 당신이 그동안 이런 개념이 없었던 자바환경에서 개발을 했기 때문에 나온 것이구요.
제가 마음에 들지 않는 것은 실제 닷넷개발자도 아닌 자바개발자가 닷넷에 대해 이런저런 이유를 들먹이며 비난하는 것입니다.
닷넷이라는 개념 나온지 얼마 안됐구요.
시작부터 완전하리라 기대하는 개발자 없습니다.
단지 적용된 개념과 앞으로의 발전가능성에 기대를 하는 것이지요.
이제 시작인 것에 온갖 부정적 이유를 갖다 붙이는 자바개발자를 정상으로 보기는 힘듭니다.
옥에 티지만, Python 은 보통 C Python을 의미하며,jvm
옥에 티지만, Python 은 보통 C Python을 의미하며,
jvm상에 돌아가는 Python은 jython 입니다.
http://www.jython.org/
몇몇 작업 하면서 사용을 해 보았는데, 쓸모 있습니다.
님의 말씀에 저도 .net이 들고나오는 멀티 언어지원에 대하여
각 언어가 가지는 컴포넌트의 특성을 저해한다는 느낌도 듭니다.
jython 경우도 역시 jython으로 만든 .class 를 java 에서
import하기 위해서는 jython 내부에 몇가지 키워드를 추가해야 합니다.
간단하지만, 간과할수 없는 문제지요. .net 역시 마찬가지로 생각됩니다.
제가 알기로는 닷넷의 스펙이 -정확한 명칭이 기억이 나지는 않지만-세계
제가 알기로는 닷넷의 스펙이 -정확한 명칭이 기억이 나지는 않지만-세계 표준 기구에 속한 것으로 알고 있습니다. 그 스펙을 참조하면 누구라도 닷넷의 vm을 개발할 수 있을 것입니다.
예전에 닷넷 세미나에 참석하고 몇몇 자료를 읽고서 추측하건데, 닷넷의 무서움은 vm을 상용으로 비싸게 판매하는 것보다 인터넷 서비스 시장을 주도하게 되는 것에 있습니다. 엠에스는 이미 엠에스엔이 패스포트를 통해 많은 사람들을 확보하였습니다. 닷넷은 분산객체를 지원하며 웹폼과 윈품을 하나로 통합한 프레임웍입니다. 즉 머신과 운영체제,그리고 네트웍에 대해서 개발자에게 투명성을 제공합니다. 닷넷 프레임워으로 개발된 서비스가 있다면, 그것이 어느 컴퓨터에 있든지 알 필요가 없으며 네트웍이나 운영체제의 하부구조에 대해서도 알 필요가 없이 닷넷의 인터페이스로 이용가능합니다. 또한 웹폼과 윈폼으로 동일하게 접근이 가능하게 됨으로 웹서비스를 브라우저 뿐만 아니라 다른 여러 윈폼으로 제공받을 수 있습니다.
이미 전술한 바와 같이 엠에스엔과 패스포트가 상당히 비대해졌습니다. 사견으로 패스포트와 엠에스엔은 닷넷 시장을 확대할 핵심적인 무기일 것입니다. 과거 윈도우즈OS가 엠에스 제품을 확대한 핵심적인 무긴였던 것 처럼... 어떤 사업자가 새로운 컨텐츠를 개발하고 그것을 패스포트와 연동하는 것만으로도 엄청난 유저를 확보할 수 있을 것입니다. 또한 패스포트 이용자는 로그인을 한 것만으로도 인테넷의 수많은 서비스를 자유롭게 이용하게 되는 것이구요. 저는 이 생각(공상일지도...?)을 하고는 소름이 끼쳤습니다.
아직 닷넷의 여러가지 면에서 성장하지 못하였기에(대표적으로 보안은 상당히 취약하답니다) 당장은 이런 일이 일어나지는 않겠지만, 만약... 엠에스가 인터넷 서비스를 장악한다면... 허걱....
(위 내용 중에 정확하지 않는 내용도 있겠지만, 대략적으로 맞을 것입니다.)
닷넷 자체는 ECMA에 제출되어 있지만 그렇다고 누구나 VM을 만들 수
닷넷 자체는 ECMA에 제출되어 있지만 그렇다고 누구나 VM을 만들 수 없습니다.
JVM 스펙은 훨씬 이전부터 공개되어 왔고 심지어 소스까지 볼 수 있지만 아직까지도 Classpath, Kaffe, Kissme등 여러 오픈소스 JVM프로젝트는 자바2 구현에 다다르지 못하고 있습니다. 이 부분은 썬 역시 동일한 이유로 비판받을 수 있는 근거를 제시합니다.
그럼 모노프로젝트는 뭔가?설명좀 해보시요.
그럼 모노프로젝트는 뭔가?
설명좀 해보시요.
선택은 자유!선택에 따른 결과는 자신이 떠 안으면 됨.남 걱정하지
선택은 자유!
선택에 따른 결과는 자신이 떠 안으면 됨.
남 걱정하지 마시고 자신의 일이나 염려하시길.
윗글 분위기 보니 lamp님이 쓴글 같은데...당신도 다른사람이 뭘
윗글 분위기 보니 lamp님이 쓴글 같은데...
당신도 다른사람이 뭘 선택하든 상관하지 마세요.
남이야 java를 하든... linux를 하든... 남 걱정 마시고 당신 일이나 염려하시기 바랍니다.
윈도우 => 유닉스를닮고 싶은 os.net => java를 닮고 싶은
윈도우 => 유닉스를닮고 싶은 os
.net => java를 닮고 싶은 환경
결국엔 앞에서 자바 호박씨나 까더니만..
뒤에서 vm에서 돌아가는 .net을 개발을 했군여..
제가 자바에 애착을 갖는 가장 큰 이유는 객체지향적 접근이 쉽다는 점 이
제가 자바에 애착을 갖는 가장 큰 이유는 객체지향적 접근이 쉽다는 점 이외에 무엇보다 특정 벤더에 종속적이지 않다는 점입니다. 서버측에서는 그래도 MS와 자바 기반 모두 접해 봤기에 어느 정도 비교할 수 있을 것 같습니다.
MS기반 개발에서는 MS가 만든 개발툴로 MS가 정한 한 가지 방법을 가지고 프로그램을 짜서 MS가 만든 OS에 설치해야 합니다.
반면 자바의 경우 J2EE, J2SE 스펙은 하나지만 아키텍처나 개발툴, 플랫폼의 선택 가능성은 무수히 많습니다. 경우에 따라서는 웹로직, 웹스피어를 구매할 수도 있고 오픈소스 기반의 JBoss를 쓸 수 있습니다. 설계도 MVC모델 하나만 봐도 수많은 오픈소스 프로젝트 프레임워크가 공존합니다. 설치 또한 리눅스, 윈도우즈 등등을 지원하고 JVM 자체도 Sun, IBM, BEA등을 선택할 수 있습니다.
닷넷이 리눅스와 윈도우즈를 통합할 수 있다면 환영합니다. 다만 이로 인해 개발 방법이 일원화 되는 상황만은 피해야한다고 봅니다. 무조건 서버 개발은 ASP.NET,으로 데이터베이스는 ADO.NET으로 하는 식의 획일화는 리눅스의 기본 정신인 선택의 자유를 박탈합니다.
다른 예지만, 실제 오픈소스 윈도우즈 프로젝트가 있었습니다. 만일 이 프로젝트가 성공해서 MS의 개발 속도를 따라잡을 수 있었다면, 우리는 리눅스나 모질라는 버리고 윈도우즈 클론에 익스플로러 클론으로 모든 컴퓨팅 환경을 통일했어야 할까요?
또한 모노가 MS에 독립성을 유지할 수 있다고 보지 않습니다. 상식적으로 생각해 봅시다. 모노는 몰라도 어차피 윈도우즈 닷넷의 방향은 MS가 결정합니다. 그렇다면 모노가 데스크탑 시장의 98%를 장악한 운영체제 와의 호환성을 무시할 수 있다고 보십니까?
쉽게 예를들어, 실제로는 몇년이 걸릴 지 모르지만 모노가 리눅스에 닷넷을 포팅해서 MS 오피스를 돌릴 수 있게 됐다고 가정합니다. 그래서 MS는 리눅스 사용자까지 시장으로 삼을 수 있게됐습니다. 그런데 차기 버전의 오피스에서 윈도우즈 닷넷의 확장 기능을 사용하면서 더 이상 이전버전의 모노에서 오피스가 동작하지 않는다고 칩시다. (실패했지만 바로 J++의 전략이었습니다)
그러면 MS가 모노에 맞추어서 오피스 차기버전을 만들겠습니까, 아니면 모노가 호환성 확보를 위해 MS가 정한 방향대로 따라가겠습니까?
아무리 오픈소스 프로젝트로서 모노의 동기가 순수해도 현실을 무시할 수는 없습니다.
그럼...
.NET의 오픈 소스 버전http://geekforum.kldp.or
.NET의 오픈 소스 버전
http://geekforum.kldp.org/stories.php?story=01/07/09/2838788
Mono Project launched.
.NET, UNIX/LINUX 표준 컴포넌트 환경이 될까요?
http://geekforum.kldp.org/stories.php?story=01/12/13/9450613
The JIT engine can now run all the compiler regression tests
.NET기반의 GNOME?
http://geekforum.kldp.org/stories.php?story=02/02/06/0177346
Mono 0.8 has been released!
리눅스, 닷넷을 끌어안아라
http://geekforum.kldp.org/stories.php?story=02/10/05/3903959
Mono 0.16 released
리눅스에서 닷넷을 구현하는 것이 못마땅할 이유가 뭘까?왜 자바 개발자
리눅스에서 닷넷을 구현하는 것이 못마땅할 이유가 뭘까?
왜 자바 개발자는 부정적 의견만 표출할까?
자신이 "이것이 아니다"라고 판단했다면 자신의 길을 선택해서 가면 그뿐 아닌가?
왜 도시락 싸들고 다니면서 반대할까?
모노프록젝트는 궁극적으로 MS코드로부터 독립적인 구현을 고려하여 추진되고 있다는 데 왜 MS를 자꾸 끌어들이는가?
반대하는 이들은 모노프로젝트에 대해 심도있게 살펴보고 그런 주장을 하는 것일까?
???????
나는 정말 궁금해
도시락 싸들고 다니면서 도시락(밥그릇)지키는 것은 아닐지...
도시락 싸들고 다니면서 도시락(밥그릇)지키는 것은 아닐지...
자바 개발자는 개구리 올챙이적 생각 못하는 우를 범하고 있습니다.자바
자바 개발자는 개구리 올챙이적 생각 못하는 우를 범하고 있습니다.
자바가 지금까지 오는데 거의 10년이 걸렸지만 .net는 개발자의 규모나 MS의 능력을 고려하면 몇년이면 완벽해질 것입니다.
닷넷에 대해 비판하는 이유를 모르신다면 아래 글들을 객관적 시각으로 천천
닷넷에 대해 비판하는 이유를 모르신다면 아래 글들을 객관적 시각으로 천천히 다시 읽어 보시기 바랍니다. 핵심은,
(1) 닷넷의 방향을 설정하는데는 무엇보다 MS의 입김이 크게 작용할 것이다.
(2) 개발 프레임워크가 일원화되거나 특정 기업에의해 독점되는 것은 바람직하지 않다.
두 가지라고 생각합니다. 저는 오히려 자바 이야기만 나오면 인신공격까지 일삼으며 깎아내리는 사람들을 이해 못하겠습니다. 개인적으로 위의 두 가지 문제만 아니라면 리눅스 상에서 자바와 닷넷이 공존하는 그림이 제일 바람직하게 생각됩니다.
참고: Java를 비판하는 이유입니다.(1) Java의 방향을 설
참고: Java를 비판하는 이유입니다.
(1) Java의 방향을 설정하는데는 무엇보다 SUN의 입김이 크게 작용할 것이다.
(2) 개발 프레임워크가 일원화되거나 특정 기업에의해 독점되는 것은 바람직하지 않다. (실질적으로 SUN에서 내놓은거 쓰는거 아닌가요?)
JCP에 대해 좀 더 알아보시는 것이 좋을 듯 합니다.기본적으로
JCP에 대해 좀 더 알아보시는 것이 좋을 듯 합니다.
기본적으로 MS의 닷넷에 대한 영향력과 자바에 대한 썬의 영향력은 근본부터 차이가 있습니다.
우선 썬은 데스크탑 시장의 98%를 장악한 운영체제를 가지고 있지 않습니다. 넷스와 익스의 경쟁 과정을 보면 그 차이가 얼마나 큰지 짐작할 수 있습니다. 더구나 클라이언트 시장에서 자바의 입지는 무시할 수 있을 정도인데 이 걸 가지고 개발 프레임워크 일원화를 걱정하기는 무리가 있지 않을까 싶군요.
그리고 그놈이나 KDE의 차기버전을 자바로 만들려고 생각하는 사람은 아무도 없습니다.
그리고 아래글에서 누차 지적한 것처럼 닷넷이 MS의 구현, 즉 제품이라면 자바는 JCP에 의해 정의된 스펙에 불과합니다. 자바의 모든 공식적인 API들은 JCP에 의해 결정되며, 이에 대한 참조구현과 호환성 테스트 킷이 함께 제공되는 것으로 알고 있습니다. 실제 JAVA2를 지원하는 JVM만 해도 Sun, BEA, IBM, Blackdown 등 다양합니다. J2EE 어플리케이션 서버의 종류는 많이 쓰는 것만 수십 가지가 넘습니다. 또한 실제 개발에 쓰이는 프레임워크나 라이브러리들은 아파치와 같은 오픈소스 그룹이 담당하는 경우가 많습니다.
써드파티 윈도우즈 닷넷이 나올 수 있을까요? 현실적으로 비주얼 스튜디오를 사용하지 않고 MS 솔루션을 개발할 수 있나요?
이런 차이를 무시하고 단순하게 "MS나 썬이나 다 똑같은 놈들이다"라는 주장만 되풀이하는 건 의미가 없습니다. 그리고 저는 썬을 옹호하는 입장은 아닙니다. 썬이 망해도 자바가 없어지지는 않습니다.
그럼...
델파이, 파워빌더 도 닷넷 버전 나온답니다.그리구 ECMA 표준 거쳐
델파이, 파워빌더 도 닷넷 버전 나온답니다.
그리구 ECMA 표준 거쳐서..내년 1월달에 ISO 표준 나오구요..
T.T...참고로 JCP는 SUN이 맹글엇고,.요즘 그것때문에 분쟁이 가끔 있져..심하게여.....T.T
리눅스에 모노 올라가면 그게 윈도우 닷넷이랑 뭐가 틀리져? ㅋㅋㅋ
썬이 더 나쁜넘이져...ㅋㅋㅋ
모노는 다중 언어를 지원해야 하기때문에.. GTK기반이던가....
모노는 다중 언어를 지원해야 하기때문에.. GTK기반이던가....
자바가.. 손좀 봐서.. 닷넷같이 만들면.. 괜찮을텐데.. 그럼 모노가 필요 없을지도... .. 서버쪽 프로그램밍만 주로 하는 자바로는 클라이언트 어플리케이션의 발전에 미치는 영향력이 너무 미비하지만.. 닷넷의 개념은 클라이언트 어플리케이션의 발전에.. 어느 정도 영향을 미칠꺼라 생각합미다.. 어플리케이션 부족에 빠지지 않을려면 말이죠.. 어플리케이션 업체쪽에서도 리눅스 진영의 어플리케이션 개발을 더욱 쉽게 할수 있고 말이죠.. 지금 처럼 윈도우즈 위주의 어플리케이션 개발방법이 바뀌지 않을껍미다.. 누가 돈안되는 리눅스 어플리케이션에 용감하게 도전하겠습미까.. MFC가 리눅스로 포팅되지는 않겠지만.. 이제 시작하는 C#이나 닷넷은 다름미다.. 그냥 공짜로 던져주는 마약이 될런지 모르지만.. 만약 그런다면.. 열라 욕먹는 선에서 끝나지는 않을껍미다.. 그리고 사실 닷넷이든,자바든 C++이든 C든.. 그게 무슨 상관이겠습미까... 리눅스 유저가 자바만 할줄 안다면.. 무슨 재미입미까..?
아래 닷넷에 대해 비판적으로 쓴 사람이지만, 사실 저 역시도 닷넷으로 인
아래 닷넷에 대해 비판적으로 쓴 사람이지만, 사실 저 역시도 닷넷으로 인해 윈도우즈 클라이언트 어플이 리눅스에 포팅될 수 있었으면 합니다. 하지만 단순히 닷넷의 컴포넌트를 GTK나 QT의 네이티브 위젯에 매핑하는 방식으로는 한계가 있습니다, 자바에서도 AWT가 그랬고 SWT도 이 점에서는 문제가 있습니다.
문제는 플랫폼 간의 최대공약수가 되는 위젯만으로는 UI가 너무 빈약하고 다른 위젯을 확장해서 플랫폼에서 지원하지 않는 위젯을 만들어내기가 거의 불가능에 가깝다는 점입니다. 반대로 GTK나 QT를 윈도우 쪽에서도 쓴다면 사용자 편의성에 문제가 있겠지요... GIMP를 윈도우즈에서 써보신 분들은 이러한 문제를 잘 알고 계시리라 믿습니다.
개인적으로 자바의 경우 AWT가 IBM의 SWT로 대체되면 문제가 나아지리라고 생각하지만 솔직히 클라이언트 자바의 갈길은 아직 멀다고 봅니다. 어쩌면 이대로 영원히 클라이언트 쪽에서 사장되고 서버와 모바일만 남을지도 모르지요... 이 부분은 공유 VM이 구현되는 JDK 1.5가 분수령이 될 것으로 보입니다.
그럼...
m$ 가 엄청난 개발비 들여서 개발한개발 플랫폼에 적당히 끼여들어서
m$ 가 엄청난 개발비 들여서 개발한
개발 플랫폼에 적당히 끼여들어서
편리함을 챙긴다..
정도 수준이면 적절한거 같습니다..
더 이상 깊이 들어가는건
싫네요....
...
뒷통수 치는 m$ 의 사기술에
한두번 당한것도 아니었고...
>>닷넷같은 공통 개발 틀을 중심으로 전세계가 >>통합되면 얼마나 많
>>닷넷같은 공통 개발 틀을 중심으로 전세계가
>>통합되면 얼마나 많은 이점이 있을 것인지 한번 곰곰
>>이 생각해 보기 바란다.
말을 좀 바꾸어 보지요, MS의 운영체제, 혹은 개발 프레임워크를 중심으로 전세계가 통합되면 얼마나 많은 이점이 있을까요?
......
글쎄요... 누구한테 이점이 있을까요? 리눅스의 핵심은 선택의 자유 아닌지...
왜 하필이면 MS쪽으로 통합을 해야하는거죠?MS가 다른쪽으로 붙으면
왜 하필이면 MS쪽으로 통합을 해야하는거죠?
MS가 다른쪽으로 붙으면 안되나?
별로 가능성은 없지만..닷넷 따라갔다가 MS가 망해버리면 어떡하실 건
별로 가능성은 없지만..
닷넷 따라갔다가 MS가 망해버리면 어떡하실 건가요?
아랫분이 지적하셨지만 MS는 구현을 하고 SUN은 스펙을 만든다고 하셨죠..
제생각에는 분명히 SUN의 경우가 훨씬 정석이라고 생각합니다.
SUN이 망하더라도 자바가 망할거라고 생각하진 않습니다.(위세는 약해지겠죠..)
하지만 MS가 망한다면,, 닷넷을 누가 나타나서 이끌어 가죠?
두리뭉실하게 모든걸 통합한다고 주장하는데,, 뭔가 확실하게 해놓고 시작했으면 합니다.
단지 자신들의 name-value가 좀 높다고 횡포를 부리는 것일 뿐이죠.
그리고 계속 SUN, 자바하고 비교하게 되는데,,
전 아무리 생각해도 SUN, 자바가 더 잘하고 있다고 생각합니다.
===============
Vas Rel Por
.NET 자체에 대한 권리JAVA 스팩에 대한 권리맞아요. S
.NET 자체에 대한 권리
JAVA 스팩에 대한 권리
맞아요. SUN에서 주장하는게 좀 더 설득력 있습니다.
사실상 MS는 라이브러리의 모든것을 공개하지 않고 있습니다.
처음 개발툴 나오고 어쩌고 할때는 물론 다 공개 했겠죠?
이게 스팩에 권리와 프로그램자체에 대한 권리의 차이겠죠.
.NET 만드는거 넘 돈든다. 아님 시장성 없다. 더이상 지원없다.
그럼 끝입니다. 아님 잘 되는데, 요 라이브러리는 우리만 쓰겠다.
그럼 평생가도 MS에서 만든 프로그램 못 따라갑니다.
언제 없어지거나 MS에 매여서 프로그램을 짤지도 모르는 서버라곤 MS서버 밖에 지원 안된는걸 믿고 쓸까요.
게다가 지금까지 보여준 MS의 행태로 봐서는 충분히 그러고도 남을 것 같습니다.
물론 SUN도 자기회사 이익이 최우선인 [기업]일테지만요.(욕할마음없습니다.)
그래도 최소한의 얌심도 없이 기업을 운영하는 MS보다는 정이갑니다.
X-BOX 장사가 안되요. 40원만 주세요
X-BOX 장사가 안되요. 40원만 주세요
난 30등. 츄베룹~ 츄베룹~ へ(￣∇￣へ) (っ￣∇￣)っ
난 30등. 츄베룹~ 츄베룹~
へ(￣∇￣へ) (っ￣∇￣)っ
네티켓의 정의Virginia Shea 3. 현재 자신이 어
네티켓의 정의
Virginia Shea
3. 현재 자신이 어떤 곳에 접속해 있는지 알고, 그곳 문화에 어울리도록 행동하라
초햏(초보 햏자)들이 아햏햏이란 이름을 더럽히는 것을 보면 햏자로써 슬퍼지는 군요.
햏자들이 모두 이런 것은 아니랍니다. :)
--
고통은 나를 강하게 할뿐.( 유수영, 2002 )
닷넷이 다중언어를 지원한다는 것이 그렇게까지 큰 이점이 된다고 생각하지
닷넷이 다중언어를 지원한다는 것이 그렇게까지 큰 이점이 된다고 생각하지 않습니다. 특히 서버측에서 닷넷이나 J2EE는 단순한 언어가 아닌 프레임워크, 혹은 패러다임 차원에서 접근해합니다. 즉, 자바 문법만 안다고 EJB를 설계할 줄 아는 것도 아니고 GNU C++에 익숙하다고 C++.NET으로 윈도우즈 프로그래밍을 할 수 있는 것도 아닙니다. 더구나 서버 프로그램을 개발할 때 외주 인력이 Cobol.NET, C#.NET, VB.NET 한 명씩 참여한다고 가정하면 유지보수의 어려움은 쉽게 짐작할 수 있습니다.
중요한 것은 만일 리눅스와 윈도우즈 모두 닷넷으로 통합된다면 이러한 패러다임 자체의 선택 가능성이 사라진다는 것을 뜻합니다.
JCP의 통제를 받는 자바를 오픈소스라고 생각하지 않는 사람들은 어차피 닷넷이 표준화 기구에 제출된 규약이기 때문에 MS의 마음대로 움직이지 않을 거라 믿습니다. 하지만 처음부터 JCP의 취지는 썬의 독점력 유지가 아닌 자바 플랫폼의 호환성을 지키려는 것이었습니다. 즉, 설사 모노가 MS와 독립적으로 닷넷 플랫폼을 발전 시킬 수 있다고 해도 윈도우즈에서 사용되는 닷넷과 호환되지 않는다면 본문에서 내세운 플랫폼 호환이나 개발비용 절감 등의 장점은 사라집니다.
반대로 모노가 철저하게 MS의 닷넷과의 호환성을 지키며 개발한다면 모노는 단지 MS 제품의 리눅스 포트이상의 의미를 부여하기 어렵습니다.
MS가 리눅스용 닷넷 제품을 저렴한 가격에 출시해서 모든 서버 어플리케이션 시장을 장악하는 것을 보고 싶지 않습니다.
저는 J2EE 프로그래머지만 만일 C#이나 C++로 EJB/J2EE를 구현해야 한다면 - 또 그게 가능 하다면 - 새로운 문법을 익힐 의향이 있습니다. 하지만 무조건 데이터베이스 접근은 ADO.NET으로, 서버 페이지는 ASP.NET으로, GUI는 윈폼으로 하는 식의 프로그램은 하고 싶지 않습니다.
개인적으로 개발 언어 자체 보다는 프레임워크, 패러다임의 독점이 더 무섭게 느껴지는 군요...
그럼...
이상하군요...Java에서 데이타베이스는 JDBC로 서버페이지는 JS
이상하군요...
Java에서 데이타베이스는 JDBC로 서버페이지는 JSP로 GUI는 AWT나 SWING으로 하지 않나요?
SUN의 프레임워크, 패러다임 독점인가요?
이건 하나도 안 무섭군요. -_-;;;
그럼...
자바를 쓴다면 그렇지요 :) 만일 썬의 영향력이 MS만큼 커져서 윈도우즈
자바를 쓴다면 그렇지요 :) 만일 썬의 영향력이 MS만큼 커져서 윈도우즈
클라이언트 조차 모두 스윙이나 AWT로 해야 한다면 당연히 지금처럼 반대
할 겁니다.
그리고 JDBC나 JSP등을 사용한다는 건 프레임워크의 선택은 아닙니다.
JDO, EJB, CASTOR, STRUTS, WEBWORK, 등등 써드 파티 프레임워크의
선택 가능성이 중요한게 아닐까요? 자바와 MS솔루션의 큰 차이중의 하나
는 아키텍처나 프레임워크 선택의 범위가 아닐까 합니다. 정해진 길로만
가면 MS쪽이 더 접근하기 쉽고 편한데 무언가 정의되지 않은 쪽을
건드릴 필요가 생기면 (프로젝트 마다 한 두개씩은 나오지요) 어려워
집니다.
누군가 그러더군요. VB는 어려운 문제를 매우 쉽게 해결할 수 있게 하지만
쉬운 문제를 매우 어렵게 풀게 만든다는 ㅡ.ㅡ;;
그럼~
상당히 비판적이신데 그럴 필요가 있을까요?어차피 남의 것 퍼다 먹는
상당히 비판적이신데 그럴 필요가 있을까요?
어차피 남의 것 퍼다 먹는 입장에서 누구는 좋고 누구는 나쁘고 .. 허허
내가 보기에 그놈이 그놈 같지만
중요한 것은 98%가 윈도우즈를 사용하고 있고 모노라는 것은 거기에 편승해서 리눅스의 사용을 획기적으로 늘릴 수 있는 방편이 될 수 있을 것이라는 겁니다.
백날 자바 사용해봐야 실질적으로 리눅스의 사용확대와는 무관한 것 같아요.
실증적으로 자바가 개발된지 꽤 오래되었지만 오히려 그 기간동안 윈도우의 시장 점유율이 더욱 늘지 않았나요?
오히려 지금은 자바VM은 윈도우즈 클라이언트가 대부분이 된 상황에서 솔라리스가 윈도우즈와의 매개를 위해서 생긴 것 같다는 느낌까지 드는데..
MS 나쁜놈이라지만 썬사는 한술 더뜨지 않나?
서버측면의 시장상황을 간과하고 계신 듯 합니다. 클라이언트에서 자바는 거
서버측면의 시장상황을 간과하고 계신 듯 합니다. 클라이언트에서 자바는 거의 사장된지 오래입니다만 (개인적으로 1.5 이후를 기대하긴 합니다) 서버측, 특히 기업 규모의 어플리케이션에서는 거의 표준으로까지 인식되고 있을 정도로 널리 사용 중입니다. 닷넷은 바로 이런 J2EE의 시장을 점유하기 위한 전략입니다.
모노를 통해 윈도우즈 클라이언트 프로그램을 리눅스에서 돌릴 수 있다면 저 역시 리눅스 저변확대를 위해 바람직한 일이라고 봅니다. 다만 경계해야 할 일은 닷넷으로 인해 특히 서버측 컴퓨팅 환경에서 개발 프레임워크/패러다임의 선택 가능성이 사라지는 것입니다. 단순히 썬이 MS보다 좋다는 식의 주장으로 인식되지 않았으면 합니다.
또 한가지 중요한 차이는 썬은 스펙으로 장사를 하지만 MS는 구현으로 돈을 번다는 점입니다. J2EE 어플리케이션 서버는 오픈소스 기반을 포함해 수십여개가 되지만 윈도우즈 닷넷이 발표된 이후 기업규모 서버 어플리케이션을 수용할 수 있는 써드파티 닷넷 플랫폼이 출현할 수 있다고 보지는 않습니다.
그럼...
글쎄요?댁께서 j2ee이용하여 기업솔루션을 개발하거나 사용하신다면 저
글쎄요?
댁께서 j2ee이용하여 기업솔루션을 개발하거나 사용하신다면 저보다 더 전문가이시니 전문적인 측면은 접기로 하지요.
한데 그 서버측 자바라는 것이 결국은 클라이언트와의 매개가 가능해야 구현에 의미가 있지 않을까요?
그렇다면 썬사가 서버측 환경이 개발되도록 노력한 것은 왜일까요?
저는 뻔하다고 생각됩니다.
미래의 대박을 꿈꾸고 있는 거지요.
그런데 뭘로?
바로 임베디드 jvm으로요.
서버가 꼭 PC에만 연결될꺼란 생각은 시대에 뒤떨어진 생각이지요
가령 휴대폰이나 PDA에 사용되는 내용들은 결국은 어딘가에 있는 서버에 자료가 있을 것이고 이런 기기들이 그런 자료를 기기에서 구현하는 데 이용되는 기술중에 자바 브루 임베디드 리눅스가 있지요.
그런데 자바와 브루는 공짜 아닙니다. 매우 비쌉니다.
그중 자바의 경우 앞으로 가전제품과 홈오토매이션에까지 이용된다면 그 비용 상상할 수도 없습니다.
한마디로 댁은 어쭙쟎은 기술에 몰두하고 있지만 자바는 마약입니다.
대안은 임베디드 리눅스와 모노입니다.
글을 싸가지 없게 쓰려면 그나마 읽는 사람들이 그런가 할 정도로 내용은
글을 싸가지 없게 쓰려면 그나마 읽는 사람들이 그런가 할 정도로 내용은 담고 있어야 하지 않을까요.
자바의 어디가 어줍잖고, 임베디드 리눅스와 모노가 어떤 부분에서 어떻게 그 업줍잖음을 해결해서 대안이 되는지 설명좀 해주시죠.?
전 모노는 잘 모르지만 임베디드 리눅스에 대해서는 그다지 낙관하지 않습니다.
우선 대다수의 임베디드 리눅스 제품 제조사들이 GPL을 지키고 있지 않은 상황에서 리눅스가 가지고 있는 가장 큰 장점인(상업적 측면에서) 빠른 피드백에 기반한 개발 모델에 의존할 수 없습니다. 결국 임베디드 리눅스는 i386 계열의 pc에서 쌓인 신뢰성을 소비하고 있을 뿐 재생산 하지 못합니다.
또한 리눅스는 32비트 cpu(사실상 i386계열만)를 염두에 두고 설계된 커널을 가지고 있으므로 h/w 선택에 제약이 많고 또 다른 아키텍처로의 포팅이 쉽지 않습니다. 사족을 좀 붙이면 임베디드 시장에서 OS자체도 사치품에 속하지만 32bit OS라면 명품수준의 사치품이라고 봅니다. 만약에 임베디드라는게 PDA나 셀폰 같은 고가의 프로세서를 장비한 제품만을 대상으로 한다면 뭐 32bit cpu가 흔한 거겠지만요. 하지만 .net이나 java 플랫폼이 노리는 control network에 붙을 백색가전들이 32 bit cpu를 가진다... 흠... 글쎄요. 전 부정적입니다.
그리고 자바. 괜찮은 플랫폼인 거 같은데? 왜 어줍짢지?
자바 꽤 쓸만한 소프트웨어 공학툴 아닌가요? 리팩터링 툴도 잘나와있고 패턴적용하기도 쉽고 프레임웍도 여러가지 부문에서 다양하게 잘 돌아가고 있고.
지금 돌아가는 것중에 자바보다 나은게 없어보이는데 .net이야 말만 무성하지 아직 실제하고 있지 않으니까 나온 다음에 나은거 쓰면 되는 거고.
근데, 자바의 구현기술은 어줍짢다고 치드라도(동의하지는 않지만) 현재 자바로 구현되어 있는 여러가지 프레임웍이나 툴도 그렇다고 생각하시는 건가요?
모노나 .net으로 더 잘 만들수 있다라면 별로 할말없고, 있지도 않은걸 보고 무슨말을...-_-;
더 낳게 만든 언어나 플랫폼이나 혹은 뭐든 있다면 그걸 좀 가르쳐 주시길 써보고 싶네요.
조기태님 왜 익명으로 글 쓰나요? ^^
조기태님 왜 익명으로 글 쓰나요? ^^
지금 외주 회사에 들어와서 다른 컴퓨터로 작업하느라 로그인을 안했을 뿐입
지금 외주 회사에 들어와서 다른 컴퓨터로 작업하느라 로그인을 안했을 뿐입니다. J2EE와 관련한 글들은 다 제가 쓴 겁니다. 익명성을 활용해서 무책임한 주장할 생각은 없습니다.
아, 위의 글은 제가 쓴거 아닙니다. 인신공격이나 비방은 안했습니다 :)
아, 위의 글은 제가 쓴거 아닙니다. 인신공격이나 비방은 안했습니다 :)
당신은 앞으로도 지금 같으리라 생각하나?당신은 8비트 마이컴만 만지다
당신은 앞으로도 지금 같으리라 생각하나?
당신은 8비트 마이컴만 만지다 퇴출될 생각이우?
싸가지없는 글을 보니 속이 좀....
원문이 싸가지가 없다고 한거 빼곤 그다지 싸가지 없을 만한 내용을 담고
원문이 싸가지가 없다고 한거 빼곤 그다지 싸가지 없을 만한 내용을 담고 있는 글이 아닌데 이상하군요. 다만 시장에 나오지도 않은 기술을 지지한다면서 시장에서 활용되고 있는 기술을 무시하는 글이 형식은 무례하고 내용은 텅비어서 좀 근거를 대달라고 하면서 싸가지 없다고 했을 뿐인데.
홈네트웍 시장이 2005년 정도에 활성화 되기 시작하리라는게 일반적인 전망이고 3년뒤죠. 그리고 홈네트웍의 시나리오의 대부분이 통합리모콘 같은 일부 품목을 빼놓고는 현재 있는 기능의 컨트롤, s/w update, status report 정도에 머무르고 있습니다. 네트웍 기능을 빼고 보자면 사실 그다지 프로세서 파워가 필요한 일들이 아니죠.
근데 네트웍 기능도 사실 홈네트웍은 9.6kbps 급의 저속 네트웍이 표준인 추세이기 때문에 MAC 부분을 빼면 프로세싱파워가 그리 필요하리라 생가되지 않습니다. 어차피 MAC은 h/w나 별도의 component로 구성될 공산이 크므로 중앙처리장치의 프로세싱 파워를 소모할 것 같지는 않구요.
이렇게 놓고보면 8bit micom이면 사실 충분한 스펙입니다. 혹시 홈네트웍이 활성화 되서 새로운 시나리오가 마구 튀어나오게 되면 프로세싱파워가 더 필요해 지겠지만 그런 need가 실제 제품개발에 영향을 미치기 시작하는건 좀 뒤의 일이겠죠. 아마 당분간은 32 bit 프로세서나 os가 백색가전에 올라가는 일은 없을꺼라는게 제 글의 요지였고. 아래 어떤 분이 김치냉장고 류에는 32bit 프로세서가 쓰였다고 해서 over spec이 아닌가 생각은 하고 있지만 내 생각이 틀릴 수도 있겠다 생각하고 있는 중입니다.
결론은 실제 일을 하는 사람 입장에서 현재 시점에서 kvm내지는 임베디드 자바와 임베디드 리눅스를 두고 봤을때 임베디드 리눅스가 원문을 쓴 사람이 기대하는 정도에 미치지 못한다는 것을 지적하려 했을 뿐입니다.
전 8 bit 마이컴만 만지다 퇴출될 생각도 없고 사실 마이컴 쪽은 가끔 하기는 하지만 제 전문 분야도 아닙니다. 다만 이 글을 쓰신 분이 8bit 마이컴에 대해서 얼마나 알고 계시기에 아무것도 아니라는 식의, 내 느낌인가?, 단호한 표현을 쓰셨는지 궁금하고.. 자바에 대해 원문을 쓴 사람은 물었듯이 다른 대안을 가지고 자바를 어줍짢다고 했는지 궁금할 뿐입니다. 남은 그 기술로 밥 벌어먹고 사는데 그 기술이 어줍짢다거나 필요없다거나 하는 말을 하려면 뭔가 지식이 있거나 대안이 있어야 하지 않을까요?
저.. 백색가전.. 32bit 쓰는데요...
저..
백색가전.. 32bit 쓰는데요...
페이지