모노는 어떻게 될것인가?

익명 사용자의 이미지

모노의 운명 예측

1. '따라할게 없어서 MS를 따라하냐'라는 따가운 눈총속에 지미안팀 혼자서 모노를 추진한다. 고분분투하지만 결국 힘에 부쳐 이볼루션같은 어플리케이션의 문제를 해결하는 선에서만 모노를 사용하게된다. 즉 모노는 지미안만 쓰는 언어로 전락한다. 실제로 지미안팀은 System.Windows보다 System.Gtk를 먼저 개발했다

2. 모든게 다 잘되서 윈도우에서 동작하는 닷넷기반 프로그램은 모두 리눅스에서도 동작하게 된다. (리눅스로 OS를 교체결정을 할때 발생하게되는 막연한 불안감 해소에도 기여하게 될것이다)

3. 모노의 확산이 자기들에게 유리하지 않을것이란 판단을 한 MS가 느닷없이 닷넷에대한 라이센스를 주장하면서 모노는 법적 소송에 휘말린다. 법적문제가 해결되지않는 이상 모노는 비즈니스영역에는 한발짝도 진출하지 못한다. 모든 모노 지지자들은 어이가 없어진다

4. 법적문제도 해결되고 모노의 지지자들도 늘어나고 어플리케이션서버와 같은 컴포넌트 컨테이너도 등장했다. 모든게 완벽하지만 같은 객체지향언어인 자바의 영역과 겹친다. 개발자들은 자바와 모노로 나뉘어져서 종교전쟁에 가까운 소모적인 논쟁으로 빠져들뻔 했으나 결국 선의의 경쟁상대로 남는다

여러분들의 생각은 어떻습니까?

졸곰의 이미지

닷넷 프레임웍쪽에 별 관심이 없어서 생각하지 않았는데
근래의 모노 프로젝트 현황을 보니까 꽤! 많은 발전이 있었군요.

Quote:
zdnet 인용 - 베일 벗은 오픈소스 닷넷 개발툴「모노 1.0」
http://www01.zdnet.co.kr/techupdate/lecture/dotnet/0%2C39024986%2C39129024%2C00.htm

앞으로의 행보가 궁금해지는걸요?

Running in the 90's
http://spbear.com

익명 사용자의 이미지

앞으로 계속 발전해서 사용자들이 들어나고,
응용프로그램들도 많이 나올 것이라 생각합니다.
라이센스 문제는 모노 시작할때부터 언급된 것이었죠.

ggokka의 이미지

우리는 기본적으로 ASP.Net 교육을 받았거나 MS의 툴에 친숙하다면 리눅스에서 소프트웨어를 개발할 수 있도록 하고 있는 것이다.

만약 J2EE를 수행하고 싶다면 그렇게 하라. 말리지 않는다. 그러나 ASP.Net를 사용하길 원한다면 우리는 이것을 지원할 것이다. 따라서 리눅스는 윈도우에 대해 불리한 입장에 처하기보다 J2EE와 닷넷 두가지를 모두 수행할 수 있는 완벽한 선택이 됐다.

http://www.zdnet.co.kr/news/enterprise/0,39024412,39129176,00.htm

익명 사용자의 이미지

별로 좋은 입장은 아닌것 같습니다.

Quote:

리눅스는 윈도우에 대해 불리한 입장에 처하기보다 J2EE와 닷넷 두가지를 모두 수행할 수 있는 완벽한 선택이 됐다.

윈도우에서 J2EE 가 되지 않는 상황이라면 모르지만, Java는 플랫폼 독립적인데..

mono 의 절름발이 .NET 으로 인해 리눅스 가 윈도우보다 나은 입장은 절대 아니라고 보여집니다.

fender의 이미지

미겔의 생각이 어떻든 당장 모노가 엔터프라이즈 시장에서 큰 변수가 되진 않을 것입니다. 개인적으로 1-2년 간 더 MS.NET과 J2EE의 세력 다툼이 있을 것이라고 봅니다.

미겔은 기본적으로 서버측 보다는 데스크탑 분야에 관심을 가지고 있는 것으로 보입니다. 특히 J2EE 쪽에 대한 언급은 현실과 동떨어진 경우가 많은데, 위의 인터뷰 기사만 봐도 Struts 등 J2EE에 대한 책은 오라일리에서 나온 한 두권이 전부라고 하는데 아마존에서 "Jakarta Struts"라는 프로젝트 전체 이름으로 검색을 해도 500여권이 넘는 결과가 나옵니다.

누구나 자신의 분야 이외에는 잘 모르는 것이 당연하지만 미겔 같은 영향력있는 오픈소스 개발자가 MS의 보고서를 마치 객관적인 사실 처럼 그대로 인용하고 상대 기술에 대한 무지를 바탕으로 자신의 기술을 홍보하는 등 MS의 마케팅 수단으로 활용되는 걸 보면 상당히 아쉽습니다.

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

pyrasis의 이미지

현재 자바는 대부분 웹관련 시장에 포진해 있습니다. 그렇지만 일반 사용자가 사용하는 데스크탑 응용프로그램은 그다지 많지 않습니다.

닷넷의 경우 닷넷을 구성하는 라이브러리(클래스)를 살펴보면 Windows.Form이 핵심입니다. 닷넷 기반 언어인 C#혹은 VB.NET은 언어 자체가 GUI 프로그래밍을 위해서 존재한다고 해도 틀린말은 아닙니다. 물론 객체지향과 콤포넌트 기술의 발전으로 ASP.NET같은 웹 서비스도 통합되었습니다.

데스크탑 환경에서의 효용성이 자바와 닷넷의 근본적인 차이점입니다.

여기서 모노는 Windows.Form을 제외한 부분을 구현한 1.0을 릴리즈 했습니다. 모노가 ASP.NET 미는것 처럼 보이는 이유는 별거 없습니다. 그냥 리눅스에서 이런것도 된다. 정도입니다. 중소형 규모의 단일 웹 사이트 구축에는 아주 좋은 환경임에는 분명합니다. 하지만 대형 프로젝트 같은경우 자바를 쓰지 모노를 쓸 이유가 없습니다.

그래서 ASP.NET으로는 현재 확고한 위치를 차지하고 있는 자바기반의 웹, 어플리케이션 서버 시장을 무너뜨리기에는 매우 힘들다고 생각됩니다.

모노는 일단 ASP.NET으로 광고효과를 낸 뒤, 오픈소스 데스크탑 GUI 프로그래밍쪽의 환경을 변화시킬 계획인 것이죠. 현재 매우 부진한 자바의 GUI로는 큰 성과를 거두지 못하고 있습니다.(기술적으로 어떻든 간에 아무도 안쓰니까.)

게다가 GTK+ 프로그램은 C로 프로그래밍을 해야 하기 때문에 GUI를 프로그래밍 하기는 쉽지가 않습니다. (쉽다고 반론할지도 모르겠지만 순수 Win32 API가지고 메모장을 만드는것과 C#과 IDE로 한두번 그려서 만드는것 중 어느것이 쉬운지는 두말 안해도 아실겁니다.)

미겔이 모노 세미나를 열었을때 가장 처음 한 것이 ASP.NET 어쩌고 저쩌고가 아닌 모노 디벨롭을 이용한 빠른 GUI 응용프로그램 개발이었습니다.

모노는 GTK#을 계속 발전시켜서 Windows.Form의 공백을 메꿀것입니다. GTK#은 GNOME 데스크탑 환경, 기타 오픈소스 환경에 딱 맞습니다. 물론 Windows위에서도 별탈 없이 잘 돌아가니깐 이것보다 좋은것은 없죠. 물론 Windows.Form도 구현하겠죠. 이건 시간이 오래 걸리는 문제라 두고봐야 할 문제고요.

모노가 외치고자 하는 것은 우리(오픈소스 진영)도 쉽고 강력한 언어와 IDE툴을 가져보자. 입니다.

cjh의 이미지

pyrasis wrote:

모노가 외치고자 하는 것은 우리(오픈소스 진영)도 쉽고 강력한 언어와 IDE툴을 가져보자. 입니다.

제가 볼 때에는 "오픈소스로 된 멀티플랫폼용의 VM/CLI 을 갖자"입니다만.
쉽고 강력한 언어와 IDE툴은 지금도 없는게 아니겠지요... 모노나 .NET,
자바의 효용성은 멀티플랫폼/멀티언어 VM이 아닐까요?

--
익스펙토 페트로눔

fender의 이미지

pyrasis wrote:
현재 매우 부진한 자바의 GUI로는 큰 성과를 거두지 못하고 있습니다.(기술적으로 어떻든 간에 아무도 안쓰니까.)

그래도 최근 SWT/JFace의 사용이 늘어나고 Java 5에서 Swing이 상당한 발전을 보이는 등 가능성은 있다고 봅니다.

예를들어 SF.net의 전체 다운로드 순위 4위인 Azureus나 MLDonkey의 공식 GUI 클라이언트인 G2GUI, RSSOwl 등이 그런 가능성을 보여주고 있습니다.

GTK#의 최대 강점은 언어중립적인 닷넷 플랫폼의 특성을 이어받아 오픈소스 개발자들이 널리 쓰는 다양한 언어를 지원한다는 점입니다(물론 닷넷 API를 다양한 언어의 문법으로 개발한다는 효용성에 대한 논란은 있을 수 있습니다).

반면 SWT의 경우 기본적으로 자바 종속적이라는 단점이 있지만 무엇보다 GTK#과 달리 리눅스, 맥, 윈도우즈 등에서 네이티브 위젯을 사용한다는 장점이 있습니다. 현재 SWT를 제외하고 이런 기능을 지원하는 오픈소스 툴킷은 제가 아는 한 wxWindows 밖에 없습니다. 자바의 경우 이미 Java-GNOME이라는 공식적인 그놈 바인딩이 있으며 기본적으로 GTK#과 동일한 기능을 갖습니다. 다만 자바의 경우 SWT의 네이티브 툴킷 지원이나 RCP와 같은 상위구조, 그리고 최근에는 이클립스 VE와 같은 위지위그 개발환경을 가지고 있기 때문에 굳이 Java-GNOME으로 리눅스 GTK에 최적화된 어플리케이션을 제작할 이유가 없을 뿐입니다.

어쨌든 특별한 이벤트가 없는한 서버측은 J2EE와 MS.NET의 싸움이 당분간 지속될 것이고 윈도우즈 클라이언트에선 MS.NET이 주도하는 가운데 SWT, GTK/GTK#, WX 등등을 사용한 오픈소스 어플리케이션이 속속 등장해서 MS.NET을 위협할 것입니다. 리눅스의 경우 모노의 영향으로 GTK#의 사용이 꾸준히 늘어날 것으로 보며 기존 GTK+/QT와 경쟁할 것이라고 생각합니다.

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

익명 사용자의 이미지

cjh wrote:
pyrasis wrote:

모노가 외치고자 하는 것은 우리(오픈소스 진영)도 쉽고 강력한 언어와 IDE툴을 가져보자. 입니다.

제가 볼 때에는 "오픈소스로 된 멀티플랫폼용의 VM/CLI 을 갖자"입니다만.
쉽고 강력한 언어와 IDE툴은 지금도 없는게 아니겠지요... 모노나 .NET,
자바의 효용성은 멀티플랫폼/멀티언어 VM이 아닐까요?

Glade나 anjuta같은 IDE가 있지만 여전히 GTK+에 C언어 기반이라 근본적인 해결책이 되지 못한다고 생각합니다.

pyrasis의 이미지

fender wrote:
pyrasis wrote:
현재 매우 부진한 자바의 GUI로는 큰 성과를 거두지 못하고 있습니다.(기술적으로 어떻든 간에 아무도 안쓰니까.)

그래도 최근 SWT/JFace의 사용이 늘어나고 Java 5에서 Swing이 상당한 발전을 보이는 등 가능성은 있다고 봅니다.

가능성이 있는것과 이미 GUI를 전제로 만들어진 닷넷은 비교대상이 되지 못합니다.

점유율 측면에서 보더라도 현재 Windows를 끼고 가는 것과 혼자 노는것은 천지차이니깐 말이죠. :wink:

fender wrote:

어쨌든 특별한 이벤트가 없는한 서버측은 J2EE와 MS.NET의 싸움이 당분간 지속될 것이고 윈도우즈 클라이언트에선 MS.NET이 주도하는 가운데 SWT, GTK/GTK#, WX 등등을 사용한 오픈소스 어플리케이션이 속속 등장해서 MS.NET을 위협할 것입니다.

위협한다기 보다는 대부분의 GUI 툴킷들이 닷넷기반으로 이전하겠죠. 이미 GTK#과 WX.NET이 있죠.

Win32 GUI의 경우 지금이나 예전이나 MFC가 버젓히 존재 하지만 볼렌드의 VCL을 많이 쓰는것이 한 예이죠.

GUI는 어떻게 하던간에 Windows위에서 놀려면 닷넷 프레임워크 안으로 흡수될수밖에 없습니다..

fender의 이미지

pyrasis wrote:
가능성이 있는것과 이미 GUI를 전제로 만들어진 닷넷은 비교대상이 되지 못합니다.

점유율 측면에서 보더라도 현재 Windows를 끼고 가는 것과 혼자 노는것은 천지차이니깐 말이죠. :wink:


인정합니다. 다만 말씀하신 것처럼 아무도 안쓰지는 않는다는 걸 강조하고 싶었을 뿐입니다 :)

다만 윈도우즈에서 SWT나 기타 오픈소스 GUI 툴킷의 미래를 그렇게 어둡게 보지는 않습니다. 만일 리눅스나 맥의 사용자가 늘어나면 한번 개발해서 윈도우즈 뿐 아니라 이들 플랫폼에서도 네이티브하게 보이는 응용프로그램을 만들려고 하는 프로그래머나 기업이 늘어날테니까요. 최소한 빠른 시일 안에 이를 충족하는 리눅스/맥 버전 MS.NET이나 모노의 WinForms 구현이 가능하다고 보지 않습니다.

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

vacancy의 이미지

WinForms는 Wine Library로 구현한다고 되어있었던 것 같은데,

제가 알고 있는 것이 틀린 것인가요 ?

저게 사실이라면 거의 구현된 거나 다름없는 것이 아닌지 ..

pyrasis의 이미지

fender wrote:

pyrasis wrote:
위협한다기 보다는 대부분의 GUI 툴킷들이 닷넷기반으로 이전하겠죠.
Win32 GUI의 경우 지금이나 예전이나 MFC가 버젓히 존재 하지만 볼렌드의 VCL을 많이 쓰는것이 한 예이죠.
이런것도 어떻게 하던간에 닷넷으로 흡수되는 결과입니다.

대부분의 툴킷이 닷넷 기반으로 이전한다는 건 좀 무리가 있다고 봅니다. 최소한 윈도우즈에서는 대다수의 응용프로그램이 MS.NET으로 이행할 것으로 봅니다만 이건 그래픽 툴킷이 아니라 응용프로그램에 대한 이야기일 뿐, 윈도우즈에서 사용할 수 있는 기타 그래픽 툴킷 - wxWindows, SWT, Swing, GTK, QT, Tk 등이 곧 닷넷 기반으로 재작성될 거라고 보진 않습니다.

일단 SWT나 Swing같은 자바 기반의 툴킷은 이전해봐야 별 매리트가 없을 것이고 현재로서는 WX.NET과 GTK#은 이미 구현됐고 QT등이 가능성이 있겠군요.
뭐 어떻게 하던간에 모노는 GTK#은 기본이고 차후 Windows.Form도 구현할것이니 모두 돌릴수 있다는것이 좋은것이죠.

fender wrote:

물론 GTK#의 경우 GTK가 닷넷으로 이행했다고 할 수 있지만 지금 윈도우즈에서 많이 쓰이는 GTK 기반 응용프로그램 - xchat, gimp 등이 닷넷으로 포팅되지 않는 한 당장의 가시적인 변화는 없다고 봐야 하지 않을까요?

이미 GTK 간판 프로그램인 에볼루션이 재작성 되고 있고
xchat, gimp가 닷넷으로 포팅되면 뭐합니까.. 쓰는 사람은 우리 오픈소스 진영밖에 없는데.

fender wrote:
문제는 WinForms를 사용하는 MS.NET 데스크탑 응용프로그램을 기타 오픈소스에서 널리 쓰이는 크로스플랫폼 툴킷들이 얼마나 따라잡을 수 있는 가 입니다. 그리고 개인적인 생각으로는 그렇게 까지 비관적으로 전망하지는 않습니다.

Windows.Form을 왜 따라잡아야 하죠?

앞서 말한 VCL같은 경우 MFC안쓰고 볼렌드 VCL을 많이 쓴다고 해서 Windows에서 VCL이 실행 되지 않도록 막았습니까?

닷넷도 마찬가지 입니다. Windows.Form이 마음에 안들면 GTK#과 WX.NET쓰면 됩니다. 아니면 볼렌드의 VCL.NET써도 되고요.

그리고 제가 비관적으로 본건 자바 진영의 GUI 툴킷 밖에 없다는 걸 강조하고 싶었을 뿐입니다. :lol:

pyrasis의 이미지

vacancy wrote:
WinForms는 Wine Library로 구현한다고 되어있었던 것 같은데,

제가 알고 있는 것이 틀린 것인가요 ?

저게 사실이라면 거의 구현된 거나 다름없는 것이 아닌지 ..

Wine 라이브러리가 그리 썩 좋은 물건이 아니라서 Wine을 배제하고 순수하게 새로 Windows.Form을 구현하기로 결정났습니다.

fender의 이미지

vacancy wrote:
WinForms는 Wine Library로 구현한다고 되어있었던 것 같은데,

제가 알고 있는 것이 틀린 것인가요 ?

저게 사실이라면 거의 구현된 거나 다름없는 것이 아닌지 ..


문제는... 과연 리눅스 사용자들이 GTK/QT를 놔두고 WINE으로 응용프로그램을 개발하고 사용하려 하는지 여부입니다.

어쩔 수 없이 기존 윈도우즈 어플리케이션이나 게임을 돌리려고 WINE을 쓰는 것과 처음부터 네이티브 툴킷을 두고 윈도우즈 API 클론을 이용해 개발을 하는 건 완전히 다른 이야기니까요.

그리고 개인적으로 리눅스에서 윈도우즈 베낀 API로 개발을하고 응용프로그램을 돌릴 바엔 그냥 윈도우즈 쓰는게 낫다고 봅니다. 돈이 없어서 윈도우즈 대신 그놈/KDE를 쓰는게 아니니까요...

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

익명 사용자의 이미지

fender wrote:
vacancy wrote:
WinForms는 Wine Library로 구현한다고 되어있었던 것 같은데,

제가 알고 있는 것이 틀린 것인가요 ?

저게 사실이라면 거의 구현된 거나 다름없는 것이 아닌지 ..


문제는... 과연 리눅스 사용자들이 GTK/QT를 놔두고 WINE으로 응용프로그램을 개발하고 사용하려 하는지 여부입니다.

어쩔 수 없이 기존 윈도우즈 어플리케이션이나 게임을 돌리려고 WINE을 쓰는 것과 처음부터 네이티브 툴킷을 두고 윈도우즈 API 클론을 이용해 개발을 하는 건 완전히 다른 이야기니까요.

그리고 개인적으로 리눅스에서 윈도우즈 베낀 API로 개발을하고 응용프로그램을 돌릴 바엔 그냥 윈도우즈 쓰는게 낫다고 봅니다. 돈이 없어서 윈도우즈 대신 그놈/KDE를 쓰는게 아니니까요...

Wine은 개발도구가 아닙니다. Wine으로 뭘 개발한단 말씀이신가요?
개발 방향 자체도 Windows 클론을 목표로 하는게 아닌 Internet Explorer, Photoshop 같은 특정 응용프로그램을 돌리는것이 주된 목표입니다. (이 부분은 와인 개발자에게 물어본 사항입니다.)

모노를 Wine과 같은 선상으로 보는것 자체가 잘못된 것입니다.

pyrasis의 이미지

로그인이 안됐군요.. 바로 위에글 제가 쓴겁니다.

fender의 이미지

Anonymous wrote:
fender wrote:
vacancy wrote:
WinForms는 Wine Library로 구현한다고 되어있었던 것 같은데,

제가 알고 있는 것이 틀린 것인가요 ?

저게 사실이라면 거의 구현된 거나 다름없는 것이 아닌지 ..


문제는... 과연 리눅스 사용자들이 GTK/QT를 놔두고 WINE으로 응용프로그램을 개발하고 사용하려 하는지 여부입니다.

어쩔 수 없이 기존 윈도우즈 어플리케이션이나 게임을 돌리려고 WINE을 쓰는 것과 처음부터 네이티브 툴킷을 두고 윈도우즈 API 클론을 이용해 개발을 하는 건 완전히 다른 이야기니까요.

그리고 개인적으로 리눅스에서 윈도우즈 베낀 API로 개발을하고 응용프로그램을 돌릴 바엔 그냥 윈도우즈 쓰는게 낫다고 봅니다. 돈이 없어서 윈도우즈 대신 그놈/KDE를 쓰는게 아니니까요...

Wine은 개발도구가 아닙니다. Wine으로 뭘 개발한단 말씀이신가요?
개발 방향 자체도 Windows 클론을 목표로 하는게 아닌 Internet Explorer, Photoshop 같은 특정 응용프로그램을 돌리는것이 주된 목표입니다. (이 부분은 와인 개발자에게 물어본 사항입니다.)

모노를 Wine과 같은 선상으로 보는것 자체가 잘못된 것입니다.


음... 윗글에서 제가 주장한 핵심이 바로 WINE은 개발도구가 아니라는 것입니다. 조금 문맥을 잘못 파악하신 것 같네요.

vacancy님께서 모노의 WinForms는 WINE 기반이기 때문에 이미 구현된거나 마찬가지라고 말씀하셔서 그 차이점을 설명 드린 것입니다. 그리고 와인이 윈도우즈 클론을 만드는 프로젝트라고 한적은 없습니다. 윈도우즈 API의 클론(재구현)이라고 표현했고 이는 와인 홈페이지에도 나와 있습니다.

모노에 있어서 GTK#과 WinForms의 위상은 상당히 애매모호 합니다. WINE 기반 WinForms가 개발 목적이 아니라면 결국 모노는 GUI 개발에 있어서는 MS.NET과의 호환을 포기해야 합니다. 실제 모노 개발자들이 WinForms를 이용한 개발을 어떻게 생각하는 지는 아직 모르겠습니다. 메일링에서 WinForms를 이용한 샘플 스크린샷을 보기도 했고 어쨌든 리눅스 개발자 입장에서 자신이 만든 프로그램이 윈도우즈에서도 네이티브하게 보인다는 건 큰 매력이니까요. (방금 보니 pyrasis님께서 올리신 글에 WINE 기반을 버리고 새로 구현한다는 내용이 있군요. 어쨌든 제 글의 의도는 충분히 전달 됐으리라고 봅니다)

어쨌든 지금으로서는 모노기반 WinForms를 이용한 개발은 viable한 접근이 아니라는 걸 말씀드린 겁니다.

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

pyrasis의 이미지

fender wrote:
모노에 있어서 GTK#과 WinForms의 위상은 상당히 애매모호 합니다. WINE 기반 WinForms가 개발 목적이 아니라면 결국 모노는 GUI 개발에 있어서는 MS.NET과의 호환을 포기해야 합니다.

이 부분에 대해서는 fender님께서 조금 오해하고 계신것 같군요.
Windows.Form이 없다고 해서 MS.NET과 호환을 포기할 이유는 전혀 없습니다.

부연설명을 하자면 닷넷 플랫폼에서는 모든 콤포넌트가 독립적입니다.

이 콤포넌트는 어느쪽의 프레임워크에서 실행되든 아무 문제가 없습니다.

GTK#의 경우 이 GTK# 콤포넌트 하나만 가지고 가서 Windows의 MS.NET 프레임워크 위에서 돌린다고 해도 아무 지장이 없습니다.

(GTK#이나 WX.NET, VCL.NET은 Windows.Form에 전혀 의존성을 가지고 있지 않은 독립 콤포넌트 입니다.)

GTK#으로 개발한 응용프로그램이 있고, 이걸 Windows용으로 배포하려면 인스톨러로 해당 응용프로그램과 GTK# 콤포넌트를 함께 묶어서 배포하면 됩니다. Windows.Form과는 아무 관련없이 GTK#으로 GUI 프로그램을 배포할 수 있죠.

GTK#을 인스톨러로 묶어서 배포하기 귀찮다면 GTK#의 콤포넌트 DLL을 해당 응용프로그램의 실행파일과 합쳐버리면 됩니다. (스태틱 빌드와 같은 개념입니다.)

혹자에서는 MS에서 닷넷 프레임 워크의 스펙을 제멋대로 바꿔 버려서 모노와의 호환성을 깨버릴 것이라는 황당한 주장을 하는데, 이미 있는 프레임워크의 스펙을 바꿔 버리면 MS 자신들이 만든 닷넷 기반 프로그램과 수많은 벤더들이 만든 닷넷 기반 응용프로그램을 모조리 수정해야 됩니다.

닷넷 프레임워크의 호환성을 깨는 행워는 MS에게 있어서 자살행위나 다름이 없으므로 호환성을 깨니 어쩌니 하는 말은 말도안되는 궤변일 뿐입니다.

fender의 이미지

pyrasis wrote:
이 부분에 대해서는 fender님께서 조금 오해하고 계신것 같군요.
Windows.Form이 없다고 해서 MS.NET과 호환을 포기할 이유는 전혀 없습니다.

모노/GTK#으로 윈도우즈 응용프로그램을 만들 수 없다는 말은 한적이 없군요. 다만 MS.NET에서 WinForms로 개발한 프로그램을 수정 없이 모노에서 돌릴 수 있고, 반대로 모노에서 GTK#으로 개발한 응용프로그램을 윈도우즈 기반 모노가 아닌 MS CLR에서 그대로 돌릴 수 있는 건 별문제라고 생각합니다.

pyrasis wrote:
혹자에서는 MS에서 닷넷 프레임 워크의 스펙을 제멋대로 바꿔 버려서 모노와의 호환성을 깨버릴 것이라는 황당한 주장을 하는데, 이미 있는 프레임워크의 스펙을 바꿔 버리면 MS 자신들이 만든 닷넷 기반 프로그램과 수많은 벤더들이 만든 닷넷 기반 응용프로그램을 모조리 수정해야 됩니다.

닷넷 프레임워크의 호환성을 깨는 행워는 MS에게 있어서 자살행위나 다름이 없으므로 호환성을 깨니 어쩌니 하는 말은 말도안되는 궤변일 뿐입니다.


여기에 대해서는 이미 다른 글타래에서 충분히 이야기 했기 때문에 길게 쓰진 않겠습니다. 하지만 지금 익스플로러 전용 사이트가 판을 치는 건 MS가 JScript나 DOM 구현의 인터페이스를 바꿔 버렸기 때문이 아닙니다. 최소한의 부분을 표준으로 발표하고 훨씬 많은 확장 기능을 통해 해당 기술을 독점하는 방식은 전통적인 MS의 전략이었습니다.

표준으로 발표된 부분은 닷넷 플랫폼의 극히 일부일 뿐이고 앞에서 계속 이야기한 WinForms 조차도 완전히 MS 마음대로 개발될 뿐입니다.

pyrasis님께서는 MS의 제품을 베끼는 것의 문제가 MS가 하위 호환성을 깨는 경우에 국한해서 생각하고 계시지만, 닷넷 프레임워크의 전체가 표준화 기구에 의해 정의되지 않고 MS보다 모노가 먼저 닷넷 API를 확장하고 이를 업계에서 defacto standard로 받아들이는 날이 오지 않는 한 이러한 위험은 상존하고 있습니다.

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

pyrasis의 이미지

fender wrote:

하지만 지금 익스플로러 전용 사이트가 판을 치는 건 MS가 JScript나 DOM 구현의 인터페이스를 바꿔 버렸기 때문이 아닙니다. 최소한의 부분을 표준으로 발표하고 훨씬 많은 확장 기능을 통해 해당 기술을 독점하는 방식은 전통적인 MS의 전략이었습니다.

익스플로러 문제와 닷넷의 문제는 별 연관성이 없습니다.

fender wrote:

표준으로 발표된 부분은 닷넷 플랫폼의 극히 일부일 뿐이고 앞에서 계속 이야기한 WinForms 조차도 완전히 MS 마음대로 개발될 뿐입니다.

pyrasis님께서는 MS의 제품을 베끼는 것의 문제가 MS가 하위 호환성을 깨는 경우에 국한해서 생각하고 계시지만, 닷넷 프레임워크의 전체가 표준화 기구에 의해 정의되지 않고 MS보다 모노가 먼저 닷넷 API를 확장하고 이를 업계에서 defacto standard로 받아들이는 날이 오지 않는 한 이러한 위험은 상존하고 있습니다.

"닷넷 프레임워크 전체가 표준화 기구에 의해 정의되지 않았다." 라는 말은 이 글을 보고 계신 분들에게 오해의 소지가 큽니다.
현재 이 글을 보고 계신 분들이 일일이 닷넷 프레임워크가 표준으로 제출되었는지 아닌지, 극히 일부분만 제출 되었는지 일일이 확인할 분이 들물다는 겁니다. 그냥 이 말만 믿고 아.. 저래서 닷넷이 나쁘구나.. 라고 오해할 수가 있습니다.

MS 기술이라 하더라도 잘 소화시켜 우리쪽에 도움되게 쓰면 됩니다. 무조건 배척할 필요가 없습니다. 그래서 저는 모노 프로젝트를 매우 훌륭하게 생각하고 있습니다.

그리고 ECMA에 제출되고 ISO표준으로된 ( http://www.ecma-international.org/publications/standards/Ecma-335.htm)
Common Language Infrastructure(CLI)의 경우 닷넷 프레임워크의 가장 핵심인 호환성 부분을 정의한 것입니다. 극히 일부분만 제출되었다고 하는 말은 그냥 깍아내리기식 발언밖에 되지 않습니다.

ggokka의 이미지

두분의 열띤 토론 잘 봤습니다. 배운것도 많구요.

한분은 모노가 결국 한두박자늦은 MS clone이 될 뿐 오픈소스진영에 도움은 절대 되지 않는다고 판단 하시는거군요(물론 GTK등, 독자 API를 공세적으로 주도하지 못한다면 이라는 가정을 두긴 하셨지만요)

또 한분은 모노를 오픈소스진영이 얼마든지 긍정적으로 활용할 수 있다고 판단하시는 거구요.

결국 개인적인 믿음의 문제인가요. 우리는 MS의 탐욕적이고 노련한 마케팅전략을 이미 알고 있고요. 그럼에도 '윈도우를 배우자'는 이만용씨의 언급(http://www.zdnet.co.kr/news/column/mylee/0,39024739,10066095,00.htm)이 무엇을 의미하는지도 알고 있습니다.

닷넷 개발자로서 저의 생각은요. 제가 만든 프로그램이 리눅스에서도 잘 돌아갔으면 좋겠어요. 저의 고객에게 리눅스도 가능한 머신으로 추천하고 싶기도 하고요. (물론 아직멀었습니다. com도 않돼 com+도 않돼 .... ㅋㅋ)

다양한 선택가능성이야말로 오픈소스 리눅스가 가진, 윈도우에는 없는, 생명력아닌가요.

결국 모노가 MS의 닷넷보다 항상 한두버전 늦기만한 클론신세라고 해도.
이미 우리는 더 많은걸 가지고 있지않나요.

익명 사용자의 이미지

Quote:

....
....
다양한 선택가능성이야말로 오픈소스 리눅스가 가진, 윈도우에는 없는, 생명력아닌가요.

결국 모노가 MS의 닷넷보다 항상 한두버전 늦기만한 클론신세라고 해도.
이미 우리는 더 많은걸 가지고 있지않나요.

더 많은 걸 가지고 있지는 않습니다.

오픈소스의 장점은 윈도우, 맥, 리눅스 , FreeBSD, NetBSD , 솔라리스, 등등 ..

모두의 혜택으로 작용하고 있습니다.

리눅스 만의 것이 아니라는 것입니다.

모노가 닷넷 보다 한두버전 늦기만한 클론신세가 되어서는 안된다는 것이죠.

최소한 MS의 밥그릇을 뺐을 수 있는 정도는 되어야 "더 많은 걸 가지고 있지 않나요" 가 성립이 되겠죠.

fender의 이미지

pyrasis wrote:
익스플로러 문제와 닷넷의 문제는 별 연관성이 없습니다.

과연 그럴까요? 아시다시피 IE는 발표 당시 기준으로 HTML/CSS/DOM 등의 표준을 꽤 충실히 준수 했습니다. 지금 비 IE 계열 브라우저 호환에 있어서 가장크게 문제가 되는 DOM이나 JScript의 경우도 모두 표준으로 관리되고 있습니다.

특히 IE의 JScript와 넷스케이프 자바스크립트와의 공통 분모인 ECMAScript의 경우, 이름에서 보듯이 닷넷과 마찬가지로 ECMA에서 관리되는 표준입니다. 이런 상황만 놓고 보면 MS가 표준을 충실히 지키고 버전이 올라갈 때 하위호환성만 깨뜨리지 않는다면 아무 문제가 없어 보입니다.

하지만 실상은 전혀 그렇지 않습니다. 바로 문제는 표준으로 관리되지 않는, 하위호환성과 관계없이 MS가 임의로 추가하는 확장 기능입니다. 즉, 최소한의 공통분모인 ECMAScript와 DOM 인터페이스만 건드리지 않는다면 웹페이지에서 HTC를 쓰건 스크립트를 액티브엑스로 임베드하건 DirectX 필터를 쓰건 문제되지 않는 다는 점입니다. 특히 축약된 DOM 표현식과 같이 호환되지 않을 경우 웹사이트 이용 자체가 불가능해질 수 있는 기능들은 인터넷에서 MS의 독점적 지위를 지키는 핵심적인 역할을 합니다.

MSDN의 웹 관련 섹션을 보셨는지 모르지만 IE5에서 IE6에 이르기까지 정말 셀수도 없는 많은 비표준 IE 전용 확장들이 등장했습니다. 레퍼런스에는 어떤 기능이 IE 전용이고 어떤 기능이 다른 브라우저와 호환되는지 명확하게 밝히지 않고 있습니다. 바로 이런 전략에 특히 표준이나 접근성에 대한 인식이 부족하고 보통 촉박한 프로젝트 기간에 쫓기는 국내 개발자들이 걸려든 결과가 바로 지금의 IE 전용 사이트가 판치는 우리나라의 인터넷 환경입니다.

과연 이게 모노/닷넷과 전혀 무관한 이야기일까요?

pyrasis wrote:
Common Language Infrastructure(CLI)의 경우 닷넷 프레임워크의 가장 핵심인 호환성 부분을 정의한 것입니다. 극히 일부분만 제출되었다고 하는 말은 그냥 깍아내리기 식 발언밖에 되지 않습니다.

말씀하신 표준을 이용해 모노와 같은 MS에서 독립된 닷넷 런타임 환경을 제작할 수 있고 C#언어를 쓸 수 있는 컴파일러를 만들 수 있습니다. 하지만 닷넷 자체가 아닌 닷넷을 이용해 응용프로그램을 개발하는 프로그래머에게 중요한 건 API 즉, 닷넷의 핵심 라이브러리 입니다.

아시다시피 데스크탑 응용프로그램과 웹기반 응용프로그램, 그리고 기업용 응용프로그램을 만드는데 각각 핵심이 되는 WinForms, WebForms/ASP.net, ADO.net은 ECMA 표준이 아닙니다. 즉, 모노가 이들 API를 그대로 가져다 베낄 수는 있지만 이들 API 설계에는 어떠한 영향력도 행사할 수 없고 여기에 어떤 확장 기능을 가져다 붙여도 그건 MS 마음대로 입니다.

MS가 무슨 '악의 축'이라도 되는 건 아니지만, 자사의 이익을 위해 표준을 내세워 교묘하게 경쟁 기술을 사장시키려는 시도는 이미 IE와 J++에서 명백히 보여준 바 있습니다. 지금 당장 MS가 모노에 우호적인 태도를 보이는 것은 당장 MS의 가장 큰 적은 모노가 아닌 자바이고 더구나 리눅스에서 구동되는 어플리케이션은 MS의 직접적인 시장이 아니기 때문입니다. 그런 점에서 모노를 통해 후발 기술인 닷넷으로 업계의 모멘텀을 끌어들이고 오픈소스를 지원하는 모습으로 개발자들에게 우호적인 이미지를 심어줄 수 있다면 MS입장에선 절대 손해보는 일이 아닙니다.

만일 MS가 리눅스나 유닉스 시장에 관심을 갖거나 윈도우즈 플랫폼에서 모노가 무시할 수 없는 경쟁상대로 부각되는 즉시 MS의 태도는 180도 달라질 것으로 믿습니다.

분명 IE/Jscript와 마찬가지로 MS는 자사의 닷넷 기술에 여러 비표준 확장 기술을 덧붙이고 아발론 같은 윈도우즈 플랫폼에 종속적인 기능과 연동하려 할 것입니다. 윈도우즈를 쓰는 웹개발자가 모질라 등에 무관심하듯, 대부분의 닷넷 개발자들은 자신의 응용프로그램이 리눅스/모노 위에서 동작하는 지 보단 보다 더 편리하고 강력한 MS가 제공하는 기술을 배우고 따라하기 바쁠 것입니다.

그렇게 된다면 어차피 많은 수의 윈도우즈 응용프로그램은 모노에서 정상적으로 동작하지 않을 것이고 모노는 불완전한 MS.NET의 클론으로 남을 수밖에 없습니다.

이러한 결과를 피하는 것은 애초에 모노를 와인과 같이 윈도우즈 응용프로그램을 구동하는 역할에 충실하도록 방향을 전환하거나 아예 MS.NET과의 호환을 무시하고 CLI/C#이라는 공통분모만 남긴채 그 위에 구현하는 API는 완전히 독립적인 노선을 택해야 한다고 봅니다.

제가 볼 때 모노는 이와 같은 커다란 잠재적 문제를 안고 있음에도, 모노를 리드하는 미구엘의 경쟁 기술에 무지하고 MS의 마케팅 구문을 앵무새처럼 따라하는 모습이나 메일링 등에서 이런 문제를 지적할 때마다 '닷넷은 ECMA표준이고 모노는 GPL이다'만 반복하는 모습 등에서 개인적으로 전혀 신뢰가 가지 않습니다.

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

pyrasis의 이미지

fender wrote:

... 생략 ...
만일 MS가 리눅스나 유닉스 시장에 관심을 갖거나 윈도우즈 플랫폼에서 모노가 무시할 수 없는 경쟁상대로 부각되는 즉시 MS의 태도는 180도 달라질 것으로 믿습니다.

분명 IE/Jscript와 마찬가지로 MS는 자사의 닷넷 기술에 여러 비표준 확장 기술을 덧붙이고 아발론 같은 윈도우즈 플랫폼에 종속적인 기능과 연동하려 할 것입니다. 윈도우즈를 쓰는 웹개발자가 모질라 등에 무관심하듯, 대부분의 닷넷 개발자들은 자신의 응용프로그램이 리눅스/모노 위에서 동작하는 지 보단 보다 더 편리하고 강력한 MS가 제공하는 기술을 배우고 따라하기 바쁠 것입니다.


너무 웹쪽으로 논제를 돌리지 않았으면 합니다. 세세한 기술이나 표준등을 줄창 외치다 보면 실제로 이 글을 보는 웹에대해서 전문적으로 알지 못하는 대다수의 사람들은 그다지 공감하지 못하는 상황이 됩니다.

fender wrote:

그렇게 된다면 어차피 많은 수의 윈도우즈 응용프로그램은 모노에서 정상적으로 동작하지 않을 것이고 모노는 불완전한 MS.NET의 클론으로 남을 수밖에 없습니다.

언제나 불완전한 클론을 외치시는군요.
그렇게 따진다면 MS-DOS는 CP/M의 불완전한 클론이고 Windows NT는 VMS의 매우 불완전한 재작성판입니다.

불완전한 클론이면 어떻습니까? 그 기술로 모든 사용자가 편리해질 수 있으면 그걸로 만족하면 됩니다.

개발자들 자존심이나 치켜 세우라고 있는 기술이 아닙니다.

fender wrote:

이러한 결과를 피하는 것은 애초에 모노를 와인과 같이 윈도우즈 응용프로그램을 구동하는 역할에 충실하도록 방향을 전환하거나 아예 MS.NET과의 호환을 무시하고 CLI/C#이라는 공통분모만 남긴채 그 위에 구현하는 API는 완전히 독립적인 노선을 택해야 한다고 봅니다.

만약 CLI/C# 공통분모만 떨어져 나온다고 치더라도 오픈소스 진영에 무슨 해가 됩니까? 그게 모노가 실패한 것이 됩니까? 이미 우리 오픈소스 진영은 C#이라는 새로운 언어의 근사한 컴파일러를 가지지 않았습니까?
이걸로 우리는 지긋 지긋한 구식 C/C++ 개발에서 조금이나마 발전을 이룰 수 있습니다.

리눅스, 유닉스 진영은 같은 ELF라 하더라도 바이너리 포맷이 전부 제각각입니다.
표준화된 EXE, DLL(PE) 포맷으로 리눅스, 유닉스의 고질적인 문제인 ELF 바이너리와 공유 라이브러리 문제를 해결할 수 있습니다.

fender wrote:
제가 볼 때 모노는 이와 같은 커다란 잠재적 문제를 안고 있음에도, 모노를 리드하는 미구엘의 경쟁 기술에 무지하고 MS의 마케팅 구문을 앵무새처럼 따라하는 모습이나 메일링 등에서 이런 문제를 지적할 때마다 '닷넷은 ECMA표준이고 모노는 GPL이다'만 반복하는 모습 등에서 개인적으로 전혀 신뢰가 가지 않습니다.

미겔은 이미 자신의 행보에 모든것을 걸었습니다.
옆에서 메일링 리스트로 약점을 쿡쿡 쑤신다고 해서 "그래 나 잘못했다 모노 안만들께" 이렇게 하지는 않는다는 것이죠. 이미 미겔은 컴퓨터 역사의 한 획을 그었고 지금도 그렇게 하고 있습니다.

너무 지레 겁먹는 모양새가 그리 좋아보이지는 않습니다. 우리는 모노와 그 진영을 지켜보기만 하면 될뿐입니다. 모노가 MS와 싸워서 지더라도 그때까지 만들었던 기술이 하루아침에 싹 사라지는 것이 아니죠. 언제 어떻게든 계속 이어져 나갈 것입니다.

기술은 망하지 않습니다. 다만 영업이 망할 뿐이죠.

익명 사용자의 이미지

아직은 기대 진영과 우려 진영 의 만족과 해소 를 위해 조금 부족하지 않나 합니다.

좀 더 지켜봐야 할 듯.

fender의 이미지

pyrasis wrote:
너무 웹쪽으로 논제를 돌리지 않았으면 합니다. 세세한 기술이나 표준등을 줄창 외치다 보면 실제로 이 글을 보는 웹에대해서 전문적으로 알지 못하는 대다수의 사람들은 그다지 공감하지 못하는 상황이 됩니다.

음... 논리적으로 주장을 뒷받침하기 위해 필요한 부분을 필요한 만큼 언급했을 뿐입니다. 노파심에서 짚고 넘어가지만 pyrasis님께서 MS의 마케팅 직원이 아니듯이 저도 썬과 아무 관련이 없습니다. 여기서 모노나 자바에 대해 논쟁을 하는 건 관련 업계에 종사하는 입장에서 관심이 있는 주제이기 때문입니다.

기술적인 부분에 관심이 있는 사람은 찾아보면 그만이고 제 말에 동의하지 않는다면 적절한 근거를 들어 반박하면 그만입니다. 여기서 닷넷/자바로 편갈라서 죽기살기로 상대방 흠집내기 경쟁을 할 것도 아닌데, 기술적으로 잘 알지 못하는 사람이 이해하기 어렵기 때문에 기술적인 근거로 모노를 반박하면 안된다는 건 좀 이해가 가지 않는 주장이군요. 아마 모르긴 해도 pyrasis님께서 근거로 드신 ECMA의 CLI 표준 문서를 읽어본 사람 보단 제가 예를 든 IE 전용 기능으로 인한 호환성 문제를 이해하는 사람이 더 많을 것 같습니다만...

어쨌든 필요 이상으로 방어적이거나 공격적으로 받아들이실 필요는 없어 보입니다.

pyrasis wrote:
언제나 불완전한 클론을 외치시는군요.
그렇게 따진다면 MS-DOS는 CP/M의 불완전한 클론이고 Windows NT는 VMS의 매우 불완전한 재작성판입니다.

불완전한 클론이면 어떻습니까? 그 기술로 모든 사용자가 편리해질 수 있으면 그걸로 만족하면 됩니다.

개발자들 자존심이나 치켜 세우라고 있는 기술이 아닙니다.


과거 오픈소스에 적대적 태도를 보였던 거대 독점기업의 비표준 API를 1 :1로 무작정 베끼는 것과 예로 드신 MS-DOS, WindowsNT의 경우는 별로 공통성이 없어 보입니다. 그리고 제 글을 정확히 읽으셨다면 제가 모노의 위험성을 지적한 것은 그게 개발자로서 자존심이 상해서가 아니라는 건 잘 아시리라 믿습니다.

pyrasis wrote:
만약 CLI/C# 공통분모만 떨어져 나온다고 치더라도 오픈소스 진영에 무슨 해가 됩니까? 그게 모노가 실패한 것이 됩니까? 이미 우리 오픈소스 진영은 C#이라는 새로운 언어의 근사한 컴파일러를 가지지 않았습니까?
이걸로 우리는 지긋 지긋한 구식 C/C++ 개발에서 조금이나마 발전을 이룰 수 있습니다.

리눅스, 유닉스 진영은 같은 ELF라 하더라도 바이너리 포맷이 전부 제각각입니다.
표준화된 EXE, DLL(PE) 포맷으로 리눅스, 유닉스의 고질적인 문제인 ELF 바이너리와 공유 라이브러리 문제를 해결할 수 있습니다.


여기에 대해선 제한적으로 동의합니다. 개인적으로 C#은 훌륭한 언어라고 생각하고 만일 CLI/C# 자체가 완전히 MS.NET과 별도로 발전한다면 크게 반대할 이유는 없다고 봅니다. 다만 그런 경우 어차피 호환성이 문제가 안된다면 굳이 새로운 언어나 런타임을 설계하지 않고 MS.NET을 1:1로 베낄 이유는 없다고 봅니다만 어쨌든 그리 우려할 상황은 아닐 것입니다. 하지만 노벨의 통제를 받는 모노는 분명 이제까지 ASP.NET, WinForms 등의 독점기술을 포함한 모든 MS.NET의 API를 복제하는데 전력을 다해왔고 이런 노선 자체의 위험성은 위에서 지적한 바대로입니다.

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

pyrasis의 이미지

fender wrote:

pyrasis wrote:
너무 웹쪽으로 논제를 돌리지 않았으면 합니다. 세세한 기술이나 표준등을 줄창 외치다 보면 실제로 이 글을 보는 웹에대해서 전문적으로 알지 못하는 대다수의 사람들은 그다지 공감하지 못하는 상황이 됩니다.

음... 논리적으로 주장을 뒷받침하기 위해 필요한 부분을 필요한 만큼 언급했을 뿐입니다. 노파심에서 짚고 넘어가지만 pyrasis님께서 MS의 마케팅 직원이 아니듯이 저도 썬과 아무 관련이 없습니다. 여기서 모노나 자바에 대해 논쟁을 하는 건 관련 업계에 종사하는 입장에서 관심이 있는 주제이기 때문입니다.

기술적인 부분에 관심이 있는 사람은 찾아보면 그만이고 제 말에 동의하지 않는다면 적절한 근거를 들어 반박하면 그만입니다. 여기서 닷넷/자바로 편갈라서 죽기살기로 상대방 흠집내기 경쟁을 할 것도 아닌데, 기술적으로 잘 알지 못하는 사람이 이해하기 어렵기 때문에 기술적인 근거로 모노를 반박하면 안된다는 건 좀 이해가 가지 않는 주장이군요. 아마 모르긴 해도 pyrasis님께서 근거로 드신 ECMA의 CLI 표준 문서를 읽어본 사람 보단 제가 예를 든 IE 전용 기능으로 인한 호환성 문제를 이해하는 사람이 더 많을 것 같습니다만...


일단 ECMA CLI 표준은 이 모노 토론에서 없어서는 안되는 문제라 당연히 근거로 든것이고 IE 문서 같은것은 웹 개발자가 아닌 이상 읽어볼 사람이 드물다는 겁니다. 그리고 자신의 전문분야(웹)로 논제를 끌고가다 보면 토론이 엉뚱한데로 흘러갈 우려가 있습니다. (저는 웹 전문가가 아니거든요)

fender wrote:

과거 오픈소스에 적대적 태도를 보였던 거대 독점기업의 비표준 API를 1 :1로 무작정 베끼는 것과 예로 드신 MS-DOS, WindowsNT의 경우는 별로 공통성이 없어 보입니다. 그리고 제 글을 정확히 읽으셨다면 제가 모노의 위험성을 지적한 것은 그게 개발자로서 자존심이 상해서가 아니라는 건 잘 아시리라 믿습니다.

그때 당시도 MS는 지금의 지미안(노벨) 보다 매우 작은 회사였고 디지탈 리서치가 시장을 장악하고 있었습니다. 물론 Windows NT의 경우도 DEC라는 거대한 공룡이 존재했었고요.(그때는 MS가 공룡이 아니었습니다.) 언제나 불완전한 클론을 내세우시며 불만을 토로하시기에 약간의 설명을 덧붙입니다.

fender wrote:

여기에 대해선 제한적으로 동의합니다. 개인적으로 C#은 훌륭한 언어라고 생각하고 만일 CLI/C# 자체가 완전히 MS.NET과 별도로 발전한다면 크게 반대할 이유는 없다고 봅니다. 다만 그런 경우 어차피 호환성이 문제가 안된다면 굳이 새로운 언어나 런타임을 설계하지 않고 MS.NET을 1:1로 베낄 이유는 없다고 봅니다만 어쨌든 그리 우려할 상황은 아닐 것입니다. 하지만 노벨의 통제를 받는 모노는 분명 이제까지 ASP.NET, WinForms 등의 독점기술을 포함한 모든 MS.NET의 API를 복제하는데 전력을 다해왔고 이런 노선 자체의 위험성은 위에서 지적한 바대로입니다.

"MS.NET을 1:1로 베낄 이유는 없다고 봅니다만"
이 말 자체가 저는 자존심 싸움으로 밖에 보이지 않습니다.
앞서 말씀드렸듯이 이런것은 진정한 사용자를 위한 태도가 아닙니다. 프로그램은 사용자가 쓰는 것이지 개발자만 쓰라고 있는것이 아니니깐요.
미겔을 비롯한 모노 지지자들이 MS가 이뻐서 MS 기술을 그대로 구현하려고 하는게 아니라는걸 잘 아실겁니다. 이 사람들은 사용자가 무엇을 원하는지 잘 파악했기 때문입니다.

노벨의 통제를 받건 받지 않건 그건 별 상관 없을듯 하군요. 어차피 지미안도 영리를 추구하는 회사였고 미겔의 뜻과도 잘 드러 맞았기 때문에 노벨과 한몸이 된것이죠.
지미안 제품군을 봐도 MS Exchange 커넥터 같은 MS 제품을 위한 상품도 개발을 한적이 있죠.

그리고 쓰라고 있는 API를 따로 구현하는 행위는 법적으로 아무런 문제가 없습니다.

ASP.NET에 왜그리 집착하시는지 모르겠군요. ASP.NET은 그냥 한 부분일 뿐이지 다른 대체 수단은 얼마든지 있습니다.(잘 아시는 자바 관련 제품들이 엄청나게 많이 있죠.)ASP.NET은 그리 비중있는 논제가 되지 못합니다.

매번 그다지 정확하지 못한 근거로 위험하니 어쩌니 불안감만 조장하지 마시고 진짜로 우리 오픈소스 진영에 도움이 되는쪽으로 생각했으면 합니다.
제가 보기엔 큰 문제가 없는데도 계속 위험하니 문제가 있니, 계속 그러면 모노에 대해서 잘 모르시는 분들은 정말 그런지 오해할 수도 있으니깐요.

방준영의 이미지

fender wrote:
과거 오픈소스에 적대적 태도를 보였던 거대 독점기업의 비표준 API를 1 :1로 무작정 베끼는 것

전세계 98% 사용자/개발자들이 사용하는 API가 "비표준"이라면, "표준"이란 과연 무엇인지 정의를 부탁드립니다. 자바나 유닉스 API는 표준인가요?

그리고 오픈소스에 적대적 태도를 보였단 얘기는 어폐가 있는 내용입니다. MS가 적대적인 것은 오픈소스중의 GPL이지 나머지 라이센스에 대해서는 별 불만 없습니다. 오픈소스를 지지하는 사람들중에서도 MS와 비슷한 이유로 GPL을 싫어하는 사람들이 많이 있습니다.

fender의 이미지

pyrasis wrote:
fender wrote:
과거 오픈소스에 적대적 태도를 보였던 거대 독점기업의 비표준 API를 1 :1로 무작정 베끼는 것과 예로 드신 MS-DOS, WindowsNT의 경우는 별로 공통성이 없어 보입니다. 그리고 제 글을 정확히 읽으셨다면 제가 모노의 위험성을 지적한 것은 그게 개발자로서 자존심이 상해서가 아니라는 건 잘 아시리라 믿습니다.

그때 당시도 MS는 지금의 지미안(노벨) 보다 매우 작은 회사였고 디지탈 리서치가 시장을 장악하고 있었습니다. 물론 Windows NT의 경우도 DEC라는 거대한 공룡이 존재했었고요.(그때는 MS가 공룡이 아니었습니다.) 언제나 불완전한 클론을 내세우시며 불만을 토로하시기에 약간의 설명을 덧붙입니다.

설명 하신 내용을 봐도 아직도 잘 이해가 가지 않는 군요. 제가 왜 MS의 독점 API를 1:1로 베끼면 안된다고 생각하는지에 대해선 정확히 이해하고 계신지 잘 모르겠습니다. 제 의견에 동의하시거나 반대하시거나는 pyrasis님의 자유입니다만 최소한 상대방의 의견을 반박하려면 그 사람의 주장하는 내용은 정확히 이해해야 하지 않을까 싶습니다.

당시 MS가 규모가 어쨌든 간에 그게 어떻게 모노가 오픈소스 커뮤니티에 미치는 영향에 대한 논쟁의 근거가 되는 지 이해가 가지 않습니다. 또한 모노가 MS.NET의 비표준 API를 1:1로 베끼는 것에 대한 반박으로 MS-DOS와 WindowsNT를 드셨는데 MS는 오픈소스 커뮤니티도 아니고 CP/M이나 VMS가 기술 표준도 아니며 MS-DOS나 WindowsNT가 이들 기술의 호환을 목적으로 API레벨에서 1:1로 베끼지도 않았습니다. 이 부분은 pyrasis님께서 더 설명을 해주셔야 할 것 같습니다.

pyrasis wrote:
노벨의 통제를 받건 받지 않건 그건 별 상관 없을듯 하군요. 어차피 지미안도 영리를 추구하는 회사였고 미겔의 뜻과도 잘 드러 맞았기 때문에 노벨과 한몸이 된것이죠.
지미안 제품군을 봐도 MS Exchange 커넥터 같은 MS 제품을 위한 상품도 개발을 한적이 있죠.

그리고 쓰라고 있는 API를 따로 구현하는 행위는 법적으로 아무런 문제가 없습니다.


오픈소스 프로젝트로서 모노는 어쩌면 MS.NET의 클론을 떠나서 기존 C/C++ 개발모델에 대한 대안으로 역할을 할 지 몰라도 노벨의 경우 모노에 바라는 건 모노가 리눅스/유닉스 상에서 MS.NET응용프로그램을 구동할 수 있도록 해서 틈새시장을 공략하려는 것입니다. 문제는 노벨의 상업적인 이익과 오픈소스 커뮤니티가 모노를 통해 얻을 수 있는 이익간에 간극이 있을 수 있다는 점입니다. 즉 노벨의 입장에서 모노가 MS.NET의 호환성을 유지하는 것은 무엇보다 중요합니다.

왜 모노가 비표준 API를 포함한 독점 기업의 기술을 1:1로 베끼는 것이 위험한지에 대한 제 주장은 이미 수 차례 반복했기 때문에 다시 쓰진 않겠습니다.

pyrasis wrote:
ASP.NET에 왜그리 집착하시는지 모르겠군요. ASP.NET은 그냥 한 부분일 뿐이지 다른 대체 수단은 얼마든지 있습니다.(잘 아시는 자바 관련 제품들이 엄청나게 많이 있죠.)ASP.NET은 그리 비중있는 논제가 되지 못합니다.

매번 그다지 정확하지 못한 근거로 위험하니 어쩌니 불안감만 조장하지 마시고 진짜로 우리 오픈소스 진영에 도움이 되는쪽으로 생각했으면 합니다.
제가 보기엔 큰 문제가 없는데도 계속 위험하니 문제가 있니, 계속 그러면 모노에 대해서 잘 모르시는 분들은 정말 그런지 오해할 수도 있으니깐요.


ASP.NET을 예로 든 것은 그 것이 닷넷으로 웹개발을 하는데 핵심적인 API이기 때문입니다. 이미 말씀 드렸지만 데스크탑 응용프로그램, 웹 응용프로그램, 그리고 기업용 응용프로그램을 만드는데 핵심적인 API - 즉, WinForms. WebForms, ADO.NET은 모두 표준이 아닌 MS의 독점 기술입니다. 그리고 모노는 그게 노벨의 이익 때문인지 미구엘의 생각 때문인지 몰라도 그런 비표준적 기술까지 그대로 베끼는 방향으로 가고 있습니다.

제가 pyrasis님에 대해 안타깝게 생각하는 건, 저의 주장의 핵심되는 내용 및 그 근거에 대해서는 전혀 언급 조차 안하시면서, 반대로 지엽적이거나 지극히 방어적이고 공격적인 대응 - 예를들어 근거로 든 예가 너무 일반인에게 친숙하지 못하다거나 저의 주장이 무작정 별로 정확하지 못해서 있지도 않은 위험을 부풀린다거나 하는 식의 발언을 통해 비생산적인 토론을 유도하고 계시다는 점입니다.

이 토론을 감정 싸움이나 플레임으로 만들고 싶지 않으시려면 부탁드립니다만 먼저 제가 예전에 적은 글과 이 쓰레드에서 주장한 내용을 먼저 정확히 읽고 이해한 다음에 근거를 들어 논리적으로 반박해 주셨으면 합니다.

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

방준영의 이미지

fender wrote:
다만 윈도우즈에서 SWT나 기타 오픈소스 GUI 툴킷의 미래를 그렇게 어둡게 보지는 않습니다. 만일 리눅스나 맥의 사용자가 늘어나면 한번 개발해서 윈도우즈 뿐 아니라 이들 플랫폼에서도 네이티브하게 보이는 응용프로그램을 만들려고 하는 프로그래머나 기업이 늘어날테니까요.

이렇게 현실성을 결여한 가정은 아무 의미가 없습니다. "만일 리눅스나 맥의 사용자가 줄어든다면 리눅스와 맥은 결국 망한다"는 주장과 다를 바 없는 얘기니까요. 사용자가 늘어날 수 있는 현실적인 방안이 없는데 어떻게 사용자가 늘어나리라고 가정을 할 수 있나요.

그나마 모노가 리눅스/유닉스 세계에 나타나면서 조금의 가능성이나마 생긴 것이지 현재의 리눅스/유닉스 개발 플랫폼은 윈도에 비하면 전반적으로 너무 조악하기 짝이 없습니다.

sDH8988L의 이미지

방준영 wrote:
fender wrote:
과거 오픈소스에 적대적 태도를 보였던 거대 독점기업의 비표준 API를 1 :1로 무작정 베끼는 것

전세계 98% 사용자/개발자들이 사용하는 API가 "비표준"이라면, "표준"이란 과연 무엇인지 정의를 부탁드립니다. 자바나 유닉스 API는 표준인가요?

논쟁이 이렇게 가면 잘못하면 그냥 말꼬리 잡는 식의 논쟁밖에 되지 않습니다...

그럼 전세계에서 90% 이상의 사용자들이 쓰는 Windows를 표준 OS라고 할 수 있습니까?

표준, 비표준의 의미는 국제 규약을 따르는지... 사용해도 나중에 LICENSE 문제 등 불필요한 부분 때문에 신경쓰지 않아도 되는지... 그런 의미로 이해하는 것이 좋지 않을까요?

ris81ryu의 이미지

일단 저는 비전문가고, 자기 컴퓨터가 어떻게 돌아가는지 호기심이 있는 엔드 유져로서 리눅스를 즐겨 씁니다. kldp에도 눈팅은 열심히 하는 편이고요. 혹시 실수가 있더라도 너무 아프게 때리지 말아달라는 비굴한 의미로 간단한 자기 소개를 했습니다. :-)

Quote:
ASP.NET에 왜그리 집착하시는지 모르겠군요. ASP.NET은 그냥 한 부분일 뿐이지 다른 대체 수단은 얼마든지 있습니다.(잘 아시는 자바 관련 제품들이 엄청나게 많이 있죠.)ASP.NET은 그리 비중있는 논제가 되지 못합니다.

두 분의 의견이 갈리는 부분은 이점입니다. 마소 api를 구현하는 것이 법률적으로 문제가 있는지 여부는 크게 중요하지 않습니다. 의견이 갈리는 부분은 지미안이 하고 있는 작업의 초점을 무엇이라고 보느냐입니다.

fender님은 C#과 .net의 ECMA 표준 부분을 자유 소프트웨어 진영에 도입하는 것에 대해서 크게 반대하지 않으시는 것으로 알고 있습니다. 문제로 삼으시는 점은 마소 api 제공을 주요 목표로 삼고 있다는 (또는 그렇게 파악하고 계시다는) 점입니다.

ie의 예는 pyrasis님께서 말씀하신 이유로 NT, 노벨, DEC등의 이야기보다 적합합니다.

1.이미 운영체제의 독점이 완료된 상태에서
2.기본적인 표준을 지원하고
3.거기에 추가적인 기능을 덧붙인다.
4.이것이 가장 중요한데, 어느 것이 표준이고 어느 것이 비표준인지를 혼돈시킨다.

라는 모델이죠. (모두가 동의하지는 않을지라도 동의하는 사람도 분명히 있을만한 주장이라고 생각합니다.)

저 결과는 결국 무엇이 표준이고, 무엇이 비표준인지 혼돈된 개발자들의 양산과, 마소의 비표준의 종속으로 나타납니다. 이것이 fender님께서 현재 웹 표준에 대해서 가지고 계신 시각으로 알고 있습니다.

모노에 대입하면 1은 변한 게 없고, 2번은 주로 지미안의 행보를 옹호하는 사람들의 논거인데 저 모델을 통해서 큰 의미가 없다고 반론을 제기할 수 있습니다. 3도 이미 말씀하신 asp.net의 예가 있고 확정적입니다. 그리고 4번은 과거로 미루어 외삽해야 합니다. :-)

이 모델에서 주의해서 봐야 할 점은, 과거와의 호환성 문제가 아무런 상관이 없다는 겁니다. 마소에게는 레거시를 끊을 이유가 없습니다. 그냥 새 기능을 추가하는 것으로 충분합니다.

결국 마소 api 제공을 통해서 유의미한 성과를 거두려면, 언제 무엇이 추가될지 모르는 마소 api를 계속해서 "너무 늦지 않은 시간 안에" 제공해야 하고, 기능의 추가는 위의 목표가 이루어진 다음에나 가능합니다. 너무나 요원해보이는 목표지요. 자주 말씀하시는 "영원히 불완전한 클론"은 이런 의미라고 생각됩니다. 미겔 정도 되는 쟁쟁한 인물이 이런 가능해보이지 않는 목표에 매달리는 것은 그놈 사용자로서 아까운 일입니다.

.net, C#이 잘못된 것이 아니고 asp.net을 지원하는 게 문제도 아닙니다. 이것을 중심 과제로 삼는 것이 잠재적으로 문제가 될 것이라는 겁니다. 결국 두 분이 해결하셔야 할 문제는 지미안의 목표가 .net이라는 새로운 플랫폼의 제공이냐, 아니면 윈도우와의 호환성이냐는 것에 대한 확인이라고 생각합니다. 잘 시작한, 흥미로운 주제의 쓰레드가 혹시라도 과열되는 것을 걱정해서 썼습니다. :roll:

방준영의 이미지

sDH8988L wrote:
방준영 wrote:
fender wrote:
과거 오픈소스에 적대적 태도를 보였던 거대 독점기업의 비표준 API를 1 :1로 무작정 베끼는 것

전세계 98% 사용자/개발자들이 사용하는 API가 "비표준"이라면, "표준"이란 과연 무엇인지 정의를 부탁드립니다. 자바나 유닉스 API는 표준인가요?

논쟁이 이렇게 가면 잘못하면 그냥 말꼬리 잡는 식의 논쟁밖에 되지 않습니다...

그럼 전세계에서 90% 이상의 사용자들이 쓰는 Windows를 표준 OS라고 할 수 있습니까?


그 점이 오픈소스 사용자/개발자들의 엄청난 착각입니다. 전세계 98%의 사용자들이 윈도가 표준 OS라고 생각하고 있는데 오직 오픈소스 사용자/개발자들만이 아니라고 애써 부정하는 거죠.

Quote:
표준, 비표준의 의미는 국제 규약을 따르는지... 사용해도 나중에 LICENSE 문제 등 불필요한 부분 때문에 신경쓰지 않아도 되는지... 그런 의미로 이해하는 것이 좋지 않을까요?

IT 산업의 전통이자 특징은 가장 많이 팔리는 물건이 저절로 표준이 된다는 겁니다. MP3 포맷이 장악하고 있는 플레이어 시장에 OGG 전용 플레이어 출시해 놓고 "아무도 안사간다"고 소비자를 탓하면 되겠습니까. 지금 리눅스/오픈소스 쪽의 불평이 대강 그런 식입니다.
fender의 이미지

방준영 wrote:
fender wrote:
과거 오픈소스에 적대적 태도를 보였던 거대 독점기업의 비표준 API를 1 :1로 무작정 베끼는 것

전세계 98% 사용자/개발자들이 사용하는 API가 "비표준"이라면, "표준"이란 과연 무엇인지 정의를 부탁드립니다. 자바나 유닉스 API는 표준인가요?

그리고 오픈소스에 적대적 태도를 보였단 얘기는 어폐가 있는 내용입니다. MS가 적대적인 것은 오픈소스중의 GPL이지 나머지 라이센스에 대해서는 별 불만 없습니다. 오픈소스를 지지하는 사람들중에서도 MS와 비슷한 이유로 GPL을 싫어하는 사람들이 많이 있습니다.


여기서 '표준'이란 MS와 같은 특정 기업이 마음대로 개발하고 관리할 수 없는 ECMA와 같은 표준화 기구에서 관리되는 기술을 말합니다.

닷넷과 C#이 ECMA 표준이라는 사실은 저보다는 모노를 옹호하는 측에서 특히 자바에 대해 모노의 장점으로 내세운 주요한 근거의 하나입니다.

독점 기술의 API를 그대로 베껴서 만든 플랫폼, 라이브러리를 오픈소스 커뮤니티에서 받아들이는 경우 무엇보다 해당 기술의 소유권을 가진 기업에 오픈소스 커뮤니티 전체가 끌려다닐 수 있다는 비판이 많습니다. 하지만 해당 기술이 독립된 기관에서 관리되고 기술에 대한 명세 및 API를 결정하는데 참여할 수 있다면 그런 위험이 적기 때문입니다.

말씀하신 사용하는 사람이 많아서 사실상의 표준으로 인정된 것은 'de facto standard'라고 하지만 과연 MS.NET과 모노의 닷넷 구현이 차이가 있을 때 어느 쪽이 업계에서 '사실상의 표준'으로 인정 받을지는 의심의 여지도 없습니다.

그리고 '많이 쓰면 표준이고 따라서 문제가 없다'라는 걸 그대로 받아들인다면 모질라나 오픈오피스나 리눅스나 다 의미가 없는 해커들의 자기만족이 아닐까 싶습니다. 중요한 건 IE, MS 오피스, 윈도우즈는 특정 기업이 독점적으로 개발하고 모질라 등은 오픈소스로 누구나 개발하고 의견을 제시할 수 있다는 점입니다. 그게 바로 오픈소스의 핵심이고 여기 오시는 분들은 바로 그런 오픈소스의 장점을 가치있게 보시는 분들이 아닌지요...

'오픈소스에 적대적이다'라는 말이 어폐가 있다면 경쟁기술을 사장시키기 위해 정직하지 않은 방법을 써온 전례가 있다 정도로 바꿔도 될 것 같습니다. J++의 경우와 넷스케입, 리얼플레이어 정도가 그 예가 될 것입니다.

방준영 wrote:
fender wrote:
다만 윈도우즈에서 SWT나 기타 오픈소스 GUI 툴킷의 미래를 그렇게 어둡게 보지는 않습니다. 만일 리눅스나 맥의 사용자가 늘어나면 한번 개발해서 윈도우즈 뿐 아니라 이들 플랫폼에서도 네이티브하게 보이는 응용프로그램을 만들려고 하는 프로그래머나 기업이 늘어날테니까요.

이렇게 현실성을 결여한 가정은 아무 의미가 없습니다. "만일 리눅스나 맥의 사용자가 줄어든다면 리눅스와 맥은 결국 망한다"는 주장과 다를 바 없는 얘기니까요. 사용자가 늘어날 수 있는 현실적인 방안이 없는데 어떻게 사용자가 늘어나리라고 가정을 할 수 있나요.

그나마 모노가 리눅스/유닉스 세계에 나타나면서 조금의 가능성이나마 생긴 것이지 현재의 리눅스/유닉스 개발 플랫폼은 윈도에 비하면 전반적으로 너무 조악하기 짝이 없습니다.


이 부분은 준영님과 저의 시각 차이기 때문에 반박할 수가 없을 것 같군요. 어쨌든 저는 지금으로서도 리눅스나 그놈, 혹은 SWT의 미래가 밝다고 믿습니다 :)

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

fender의 이미지

ris81ryu wrote:
일단 저는 비전문가고, 자기 컴퓨터가 어떻게 돌아가는지 호기심이 있는 엔드 유져로서 리눅스를 즐겨 씁니다. kldp에도 눈팅은 열심히 하는 편이고요. 혹시 실수가 있더라도 너무 아프게 때리지 말아달라는 비굴한 의미로 간단한 자기 소개를 했습니다. :-)

Quote:
ASP.NET에 왜그리 집착하시는지 모르겠군요. ASP.NET은 그냥 한 부분일 뿐이지 다른 대체 수단은 얼마든지 있습니다.(잘 아시는 자바 관련 제품들이 엄청나게 많이 있죠.)ASP.NET은 그리 비중있는 논제가 되지 못합니다.

두 분의 의견이 갈리는 부분은 이점입니다. 마소 api를 구현하는 것이 법률적으로 문제가 있는지 여부는 크게 중요하지 않습니다. 의견이 갈리는 부분은 지미안이 하고 있는 작업의 초점을 무엇이라고 보느냐입니다.

fender님은 C#과 .net의 ECMA 표준 부분을 자유 소프트웨어 진영에 도입하는 것에 대해서 크게 반대하지 않으시는 것으로 알고 있습니다. 문제로 삼으시는 점은 마소 api 제공을 주요 목표로 삼고 있다는 (또는 그렇게 파악하고 계시다는) 점입니다.

ie의 예는 pyrasis님께서 말씀하신 이유로 NT, 노벨, DEC등의 이야기보다 적합합니다.

1.이미 운영체제의 독점이 완료된 상태에서
2.기본적인 표준을 지원하고
3.거기에 추가적인 기능을 덧붙인다.
4.이것이 가장 중요한데, 어느 것이 표준이고 어느 것이 비표준인지를 혼돈시킨다.

라는 모델이죠. (모두가 동의하지는 않을지라도 동의하는 사람도 분명히 있을만한 주장이라고 생각합니다.)

저 결과는 결국 무엇이 표준이고, 무엇이 비표준인지 혼돈된 개발자들의 양산과, 마소의 비표준의 종속으로 나타납니다. 이것이 fender님께서 현재 웹 표준에 대해서 가지고 계신 시각으로 알고 있습니다.

모노에 대입하면 1은 변한 게 없고, 2번은 주로 지미안의 행보를 옹호하는 사람들의 논거인데 저 모델을 통해서 큰 의미가 없다고 반론을 제기할 수 있습니다. 3도 이미 말씀하신 asp.net의 예가 있고 확정적입니다. 그리고 4번은 과거로 미루어 외삽해야 합니다. :-)

이 모델에서 주의해서 봐야 할 점은, 과거와의 호환성 문제가 아무런 상관이 없다는 겁니다. 마소에게는 레거시를 끊을 이유가 없습니다. 그냥 새 기능을 추가하는 것으로 충분합니다.

결국 마소 api 제공을 통해서 유의미한 성과를 거두려면, 언제 무엇이 추가될지 모르는 마소 api를 계속해서 "너무 늦지 않은 시간 안에" 제공해야 하고, 기능의 추가는 위의 목표가 이루어진 다음에나 가능합니다. 너무나 요원해보이는 목표지요. 자주 말씀하시는 "영원히 불완전한 클론"은 이런 의미라고 생각됩니다. 미겔 정도 되는 쟁쟁한 인물이 이런 가능해보이지 않는 목표에 매달리는 것은 그놈 사용자로서 아까운 일입니다.

.net, C#이 잘못된 것이 아니고 asp.net을 지원하는 게 문제도 아닙니다. 이것을 중심 과제로 삼는 것이 잠재적으로 문제가 될 것이라는 겁니다. 결국 두 분이 해결하셔야 할 문제는 지미안의 목표가 .net이라는 새로운 플랫폼의 제공이냐, 아니면 윈도우와의 호환성이냐는 것에 대한 확인이라고 생각합니다. 잘 시작한, 흥미로운 주제의 쓰레드가 혹시라도 과열되는 것을 걱정해서 썼습니다. :roll:


좋은 글 감사합니다. 적절한 시점에 적절하게 논쟁의 핵심을 잘 정리해 주신 것 같습니다 :)

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

feanor의 이미지

"표준"이란 건, 그 표준의 "구현물"이 표준에 맞지 않으면 그 "구현물"이 얼마나 유명하건간에 "니가 틀렸다"라고 까댈 수 있는 자신감을 말합니다. 적어도 저는 그렇게 생각합니다.

Win32API는 표준이 아닙니다. 왜냐하면 Wine 프로젝트에서 "MSDN 문서랑 Windows XP의 구현이 맞지 않으므로 Windows XP가 틀렸다" 라고 하고 "맞게" 구현할 수 없기 때문입니다. (Wine 소스코드 보시면 "문서와 다르다"는 식의 코멘트가 수두룩합니다.)

HTML이 표준인가요? "비표준 HTML"을 예컨대 "맥에서 잘 안 보입니다"로 까서 웹사이트가 HTML을 고치게 할 수 있어야 표준인 것입니다.

Java는 표준일까요? 최근에 오픈 소스 J2EE 구현인 JBoss를 Kaffe에서 돌리려고 했을 때, 모든 것이 제대로 돌아가는데 JBoss에서 Sun JDK의 java.util.zip 구현에 버그가 있어서 "이 버그에 맞춰서" 코딩을 하는 바람에 중간에 죽는 일이 생겼습니다. 당연히 Kaffe 프로젝트에서는 "JBoss 너네가 틀렸다. 고쳐라"고 했습니다. JBoss에서 어떻게 했을 것 같습니까? Sun JDK "문서"에 맞추는 것보다, 이전 버전에서도 "돌아가게" 하는 게 더 중요하다고 하고는 씹었습니다. Kaffe는 "Sun의 버그에 맞춰서" 패치를 만들었구요.

IETF에서 "적어도 두 개의 독립적인 구현이 있어야" 표준을 받아주는 것은 다 그러한 이유가 있는 것입니다.

--feanor

pyrasis의 이미지

괜히 제가 디지탈 리서치, DEC를 예로 들어서 한순간에 바보가 되는 상황이 되었지만

제가 세세한 기술까지 들먹이지 않는 이유가 있습니다.

fender씨처럼 전문 분야의 세세한 기술적 용어를 들먹이면서 그럴싸하게 주장을 계속 해댄다면 잘 모르는 사용자 입장에서는 믿을수 밖에 없습니다.

그래서 저는 언제나 사용자 입장에서 생각하도록 노력하고 있습니다.

방준영의 이미지

fender wrote:
방준영 wrote:
fender wrote:
과거 오픈소스에 적대적 태도를 보였던 거대 독점기업의 비표준 API를 1 :1로 무작정 베끼는 것

전세계 98% 사용자/개발자들이 사용하는 API가 "비표준"이라면, "표준"이란 과연 무엇인지 정의를 부탁드립니다. 자바나 유닉스 API는 표준인가요?

그리고 오픈소스에 적대적 태도를 보였단 얘기는 어폐가 있는 내용입니다. MS가 적대적인 것은 오픈소스중의 GPL이지 나머지 라이센스에 대해서는 별 불만 없습니다. 오픈소스를 지지하는 사람들중에서도 MS와 비슷한 이유로 GPL을 싫어하는 사람들이 많이 있습니다.


여기서 '표준'이란 MS와 같은 특정 기업이 마음대로 개발하고 관리할 수 없는 ECMA와 같은 표준화 기구에서 관리되는 기술을 말합니다.

그렇다면 자바와 리눅스 API(유닉스 API에 대한 독자적 확장으로서)는 표준이 아닌 것은 분명하군요. fender님이 선호하시는 표준이란 과연 무엇입니까? 저는 표준, 비표준을 구분한다는 것 자체에 찬성하지 않기에 이런 질문을 드리는 것입니다.

Quote:
독점 기술의 API를 그대로 베껴서 만든 플랫폼, 라이브러리를 오픈소스 커뮤니티에서 받아들이는 경우 무엇보다 해당 기술의 소유권을 가진 기업에 오픈소스 커뮤니티 전체가 끌려다닐 수 있다는 비판이 많습니다. 하지만 해당 기술이 독립된 기관에서 관리되고 기술에 대한 명세 및 API를 결정하는데 참여할 수 있다면 그런 위험이 적기 때문입니다.

아주 똑같은 얘기를 자바에 대해서도 할 수 있는데 어찌해서 fender님은 항상 자바에 편향된 주장을 되풀이 하시는지...?

Quote:
말씀하신 사용하는 사람이 많아서 사실상의 표준으로 인정된 것은 'de facto standard'라고 하지만 과연 MS.NET과 모노의 닷넷 구현이 차이가 있을 때 어느 쪽이 업계에서 '사실상의 표준'으로 인정 받을지는 의심의 여지도 없습니다.

이런 비현실적인 가정은 그만해 주시면 감사하겠습니다. AMD가 인텔 CPU와 호환이 안되면, 당연히 안팔리겠죠?

Quote:
그리고 '많이 쓰면 표준이고 따라서 문제가 없다'라는 걸 그대로 받아들인다면 모질라나 오픈오피스나 리눅스나 다 의미가 없는 해커들의 자기만족이 아닐까 싶습니다. 중요한 건 IE, MS 오피스, 윈도우즈는 특정 기업이 독점적으로 개발하고 모질라 등은 오픈소스로 누구나 개발하고 의견을 제시할 수 있다는 점입니다. 그게 바로 오픈소스의 핵심이고 여기 오시는 분들은 바로 그런 오픈소스의 장점을 가치있게 보시는 분들이 아닌지요...

소프트웨어의 가치는 그 소프트웨어를 사용하는 사용자의 수에 정확히 비례합니다. 똑같이 만든 프로그램이 하나는 100명이 쓰고 하나는 100만명이 쓴다면 어느쪽이 더 가치있는 소프트웨어인지 명확하지 않습니까. 오픈소스가 발전하려면 더 이상 자기만족 수준에 머물러 있어서는 안됩니다. 개발자 자신이 원하는 소프트웨어보다 사용자가 원하는 소프트웨어를 만들어야죠.
feanor의 이미지

RFC 2026, "인터넷 표준 절차" (Internet Standard Process) 관련 부분을 인용합니다.

4.1.2 Draft Standard

A specification from which at least two independent and interoperable implementations from different code bases have been developed, and for which sufficient successful operational experience has been obtained, may be elevated to the "Draft Standard" level. For the purposes of this section, "interoperable" means to be functionally equivalent or interchangeable components of the system or process in which they are used. If patented or otherwise controlled technology is required for implementation, the separate implementations must also have resulted from separate exercise of the licensing process. Elevation to Draft Standard is a major advance in status, indicating a strong belief that the specification is mature and will be useful.

적어도 두 개의 서로 독립적이고 호환되는 구현물이 존재하고 이들 구현물 사이에 충분한 호환성이 검증되었다면, "Proposed Standard"는 "Draft Standard"로 전환될 수 있다. 호환성이 있다 함은 기능적으로 동일하여 (functionally equivalent) 대체될 수 있음(interchangable)을 뜻한다.

--feanor

fender의 이미지

방준영 wrote:
아주 똑같은 얘기를 자바에 대해서도 할 수 있는데 어찌해서 fender님은 항상 자바에 편향된 주장을 되풀이 하시는지...?

오해가 있으신 것 같군요. 만일 지금 상황에서 예를들어 그놈이 GCJ 기반으로 바꾼다고 한다면 똑같은 이유로 반대할 겁니다. :) 어쨌든 지금으로서는 썬 자바나 MS.NET 모두 비표준 독점 기술이라는 점에선 동일하니까요. 모노에 관한 제 시각은 '모노냐 자바냐'하는 양자택일을 강요하는 것은 아닙니다.

굳이 JCP로 관리되는 썬의 자바와 일부 스펙이 ECMA로 공개된 MS.NET 중 어느 것이 더 개방적인 기술이냐를 따진다면 전 전자의 편을 들겠지만 그건 이번 논의의 핵심과는 별로 상관이 없는 것 같습니다. SWT를 비롯한 클라이언트 자바의 미래를 밝게 보는 건 개인적인 시각이고 모노에 대한 반대 이유는 아닙니다. 오해 없으셨으면 좋겠군요.

방준영 wrote:
Quote:
말씀하신 사용하는 사람이 많아서 사실상의 표준으로 인정된 것은 'de facto standard'라고 하지만 과연 MS.NET과 모노의 닷넷 구현이 차이가 있을 때 어느 쪽이 업계에서 '사실상의 표준'으로 인정 받을지는 의심의 여지도 없습니다.

이런 비현실적인 가정은 그만해 주시면 감사하겠습니다. AMD가 인텔 CPU와 호환이 안되면, 당연히 안팔리겠죠?

제가 말하고자 하는게 바로 그 점입니다만... 과연 거대 독점기업이 .NET의 방향을 주도하는 현실에서 모노가 MS.NET과 호환성을 포기하고 독자적인 길을 걷는다면 과연 '사실상의 표준'적 지위를 얻을 수 있을까요? 결국 다람쥐 쳇바퀴 돌 듯 MS가 새로운 기능을 추가할 때마다 이를 베껴야 하고, 어쩌면 MS.NET의 버그까지도 그대로 재현해야 할지 모릅니다.

방준영 wrote:
소프트웨어의 가치는 그 소프트웨어를 사용하는 사용자의 수에 정확히 비례합니다. 똑같이 만든 프로그램이 하나는 100명이 쓰고 하나는 100만명이 쓴다면 어느쪽이 더 가치있는 소프트웨어인지 명확하지 않습니까. 오픈소스가 발전하려면 더 이상 자기만족 수준에 머물러 있어서는 안됩니다. 개발자 자신이 원하는 소프트웨어보다 사용자가 원하는 소프트웨어를 만들어야죠.

이건 이번 토론과는 좀 다른 주제가 되겠지만, 예를들어 처음부터 넷스케이프의 소스를 물려받은 모질라가 '완전한 IE 클론'을 목표로 삼았다면 지금의 위치에 이르지 못했을 것입니다. 개인적으로 오픈소스의 가치는 독점 소프트웨어를 무료로 사용할 수 있다는 것이 아니라 모두가 참여해서 자유롭게 개발한다는데 있다고 믿습니다. 그런 점에서 최소한 저에게는 지금 당장 독점 소프트웨어의 점유율이 10%건 90%건 크게 중요하진 않습니다. 물론 사용자가 원하는 응용프로그램을 만들어야 한다는데는 100% 동의 합니다. 다만 반드시 그 방법이 독점 기술을 API레벨에서 1:1로 베끼는 것이 될 필요는 없다고 생각할 뿐입니다.

어쨌든 그런 시각에서는 준영님의 시각도 충분히 이해합니다만 굳이 개인적인 생각을 바탕으로 반박하고 싶진 않습니다. 이건 호기심에서 여쭤보는 것이지만 준영님께서는 ReactOS에 대해서는 어떻게 생각하시는 지 무척 궁금하네요 :)

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

sangu의 이미지

feanor의 이미지

Gnosmirc
http://gnosmirc.meebey.net/

GTK#으로 만든 IRC 클라이언트입니다.

--feanor

방준영의 이미지

닷넷 애플리케이션의 스크린샷이 이 토론과 무슨 상관이죠? 토론 물 흐리려고 일부러 그러는 것 같아서 보기가 좋지 않군요.

chunsj의 이미지

방준영 wrote:
그 점이 오픈소스 사용자/개발자들의 엄청난 착각입니다. 전세계 98%의 사용자들이 윈도가 표준 OS라고 생각하고 있는데 오직 오픈소스 사용자/개발자들만이 아니라고 애써 부정하는 거죠.

제가 보기엔 표준의 정의가 서로 다른 것 같은데요? 많이 쓰면 표준이다 라고 정했다면 당연히 방준영님의 의견이 맞겠지만, 누구나 쓸 수 있다라면 이야기는 달라집니다. 제가 보기엔 컴퓨터를 사용할 줄 아는 사람중에 윈도만 사용하거나 윈도 호환이 최고다 라고 생각하는 사람들만이 애써 그렇게 생각하는 것 같습니다. :-)

Quote:
IT 산업의 전통이자 특징은 가장 많이 팔리는 물건이 저절로 표준이 된다는 겁니다. MP3 포맷이 장악하고 있는 플레이어 시장에 OGG 전용 플레이어 출시해 놓고 "아무도 안사간다"고 소비자를 탓하면 되겠습니까. 지금 리눅스/오픈소스 쪽의 불평이 대강 그런 식입니다.

가장 많이 팔리는 물건이 중요한게 아니라, 가장 많이 팔릴 뿐만 아니라 제한이 거의 없이 생산할 수 있는 주체가 많은 물건이 저절로 표준이 됩니다. 이점은 확실히 해야 한다고 봅니다. 독점은 표준이 아니라 표준처럼 강제하는 것일 뿐이고 그때문에 제한을 받는 것입니다. 자유소프트웨어/오픈소스를 지지하는 측의 많은 불평은 바로 여기에 근원이 있습니다.

모노의 문제는 .NET이나 C#이라는 언어에 있는 것이 아니라, 영원히 호환이 될 수 없는 MS가 만들지 않는 윈도 호환 시스템과 같은 운명이라는데 있습니다. MS가 갑자기 우리는 API에 대한 구현에 있어서 표준을 항상 정의하고 오픈하겠다라고 한다면 문제가 개선될 여지가 있겠지만 지금까지 절대로 그렇게 해오지 않았고 앞으로도 별로 그렇게 할 것이라고 기대도 안합니다. 그냥 또다른 .NET 비슷한 환경, 리눅스가 유닉스에 대해서 그러하듯, 이 목적이라면 의미가 있겠지만 본 토론에서 모노에 희망이 있다라고 보시는 분들의 기대처럼 .NET을 통해서 윈도와 거의 호환될 환경이라는 점에 대해서는 별로 의미 없다고 봅니다.

sangu의 이미지

방준영 wrote:
닷넷 애플리케이션의 스크린샷이 이 토론과 무슨 상관이죠? 토론 물 흐리려고 일부러 그러는 것 같아서 보기가 좋지 않군요.

단지 GNOME 공동체에서는 mono를 MS Window에서도 돌아가는 닷넷 애플리케이션(?)를 만들기 보다는 GNOME 개발 언어중 하나로써 사용한다는 것을 보이기 위해서 스크린 샷을 남겨습니다.

ggokka의 이미지

아니지요.
논쟁의 구도가 일견 어떤걸 표준으로 보느냐로 좁혀지고 있는거 같지만요.
사실은요. MS와의 호환할거냐 말거냐죠.

(1)MS와 호환은 결국 MS종속으로 간다.
- MS와 호환하기 위해서 api를 1:1로 계속 구현해야 한다. 에러까지도 말이다.
- MS는 얼마든지 자기들에게 불리하면 MONO를 공격할것이다. 그때가서 아무런 대책이 없을것이다. 미겔 책임질거냐.
- 봐라 MS가 일부만을 표준화기구에 승인받았을뿐, Forms / Asp.net등은 승인받지 않은 비표준으로 남아있는 이유가 뭐냐.
- 실천방안 : CLI위에서 작동하지만 독립적인 API개발

(2)아니다 MS호환으로 더많은 사람들에게 어필할 수 있다.
- 전세계 피씨들이 거의다 MS Windows인데 이게 표준이 아니구 뭐냐.
- MS호환으로 리눅스를 더 많은 사람들이 쓰게하고 현대화하자.
- MS와 호환한다고 오픈소스 안하는거 아니다.
- 실천방안 : MS호환되는 API개발 + 더 많은 API개발

저의 입장은요. 2번입니다.

익명 사용자의 이미지

방준영 wrote:
닷넷 애플리케이션의 스크린샷이 이 토론과 무슨 상관이죠? 토론 물 흐리려고 일부러 그러는 것 같아서 보기가 좋지 않군요.

토론하고 계신중에 이런 말 해서 뭐하지만,

대다수 시청자(?)들은 즐거운 마음으로 이 토론이 어떤 구도가 될지 궁굼해하고
호기심어린 눈으로 지켜보고 있을거라고 생각합니다.

토론 상대자의 논리를 깨부수려고 기쓰고 덤벼드는 듯한 인상보다는...
지금 토론을 지켜보고 있는 다수의 동조자들의 참여도 생각해서 날카로움을
무디게 하셔도 나쁠것 없다는 생각이 듭니다.

상구님의 스샷은 그런 면에서 아주 좋았다고 생각합니다. =3=3=3=33

pyrasis의 이미지

Anonymous wrote:
방준영 wrote:
닷넷 애플리케이션의 스크린샷이 이 토론과 무슨 상관이죠? 토론 물 흐리려고 일부러 그러는 것 같아서 보기가 좋지 않군요.

토론하고 계신중에 이런 말 해서 뭐하지만,

대다수 시청자(?)들은 즐거운 마음으로 이 토론이 어떤 구도가 될지 궁굼해하고
호기심어린 눈으로 지켜보고 있을거라고 생각합니다.

토론 상대자의 논리를 깨부수려고 기쓰고 덤벼드는 듯한 인상보다는...
지금 토론을 지켜보고 있는 다수의 동조자들의 참여도 생각해서 날카로움을
무디게 하셔도 나쁠것 없다는 생각이 듭니다.

상구님의 스샷은 그런 면에서 아주 좋았다고 생각합니다. =3=3=3=33

사실 이런 토론에서는 그냥 어떤 어떤 프로그램이 있다. 정도만 해도 괜찮은데. 스크린샷으로 거의 한 화면을 도배하는 건 좀 부적절하다고 생각됩니다. 게다가 스크린샷을 올렸다면 그에 대한 직접적인 의견을 함께 덧붙였으면 더 좋았을 것입니다. 뒤에 문제 제기를 하니깐 답변을 해주는 것도 그다지 좋은 방법은 아니라고 생각됩니다.
사람들에 따라서는 일부러 그러려는 것 같은느낌을 받을 수도 있으니까요.

익명 사용자의 이미지

결국 말이죠. 표준이 무엇이거나 하는 싸움은 근본적 관점이 다름을 인정해야 하는 부분입니다.
위의 방준영님의 주장과는 달리 저는 궁극적으로 소비자가 진정 보호받을수 있는게 무엇인가에 관점을 돌려야 된다고 생각합니다.
대다수 사람들이 어떻게 생각하는가는 물론 중요하지만 자신 스스로 질문을 해 보았을때 과연 이렇게 흘러가는게 타당한지, 소비자에게 궁극적인 도움이 되는지를 고민해야 한다는 것이지요.

이순간 대다수의 사람들이 표준처럼 생각하는 것이라 하더라도 그것이 결국 독이 됨을 널리 알리고 일종의 여러 행동들을 해야 하는게 아닐까 합니다.

galien의 이미지

방준영 wrote:
닷넷 애플리케이션의 스크린샷이 이 토론과 무슨 상관이죠? 토론 물 흐리려고 일부러 그러는 것 같아서 보기가 좋지 않군요.

애초에 이 쓰레드는 모노의 미래에 대해서 토론하는 것 아니었나요.
물론 표준 비표준에 대해서 말하고 싶어하시는 방준영씨의 마음은
이해합니다만,

닷넷 어플리케이션(이라기 보다는 그놈위에서 도는 모노 어플리케이션)
의 스크린 샷 만큼 현재의 모노 진척상황을 간략하게 잘 보여 주는 것도
없을테고, 과거와 현재를 모르고 미래를 말할 수는 없는 것일 테니까요.

표준과 비표준, 마소의 클론이 될 것이냐, 마소의 새로운 도구를 흡수할
것이냐는 결국 어찌보면 신념에 가까운 얘기이고 사실과 허구에서는
약간 거리가 있는 정책, 나아가야 할 바에 대한 이야기입니다.

두분(혹은 네분)의 토론이 참 많은 생각할 거리를 던져주고,
무지했던 사실에대해 깨우쳐주셔서 감사합니다만, 그 중 몇 분은
상대방을 이해(설득이라기보다는)시키지 못하는 좌절감에
감정적으로 흐르지 않기를 바랍니다.

리눅스 유저라고 해서 신념이 같으란 법은 없으니, 서로 다름을
확인하고도 공존할 수 있지 않을까요.

갑자기 emacs 동료가 순식간에 철천지 원수로 변하는
유머가 생각나는 군요.

atie의 이미지

토론의 접점이 맞지 않는다는 생각입니다.

한 분은 모노 1.0에 구현된 콤포넌트들이 리눅스 데탑의 GUI 개발 환경에 도움이 될 것이라는 주장이시고, 다른 한 분은 모노 2.0에서야 어쩌면 제대로(?) 구현이 될 ASP.NET 과 Windows.Forms의 기술 기반에 대해서 이야기를 하셨습니다. 그리고 표준 기술에 대한 이야기로 넘어 갔고요.

모노의 미래에 대한 토론이라면, 주제를 좁혀서 토론을 시작해 보는 것이 좋지 않을까요? 현재의 가치가 무엇이냐 부터요.
예를 들어 (우선은 알고 싶은게), 리눅스 상의 데스크탑 어플리케이션 개발시, C#과 GTK#의 조합이 다른 여타의 (Java/SWT, C/GTK, C++/QT 등)조합에 비해 강점을 가지는가?
나아가, 크로스플랫폼에서는 어떤가?
얼마만큼의 완성된 IDE를 포함한 개발 환경을 제공하는가?
현재의 결과물의 품질은 어떻고 개발의 용이성은 어느 정도 인가?

제 개인 생각으로는, 모노의 미래는 궁극적으로 개발자의 선택에 달려 있다고 보고, 시대를 꺼구로 가는 이야기 일지는 몰라도 데스크탑(특히, 리눅스상) 어플리케이션의 수요에 직접적으로 연관이 된다고 봅니다. 이 관점에서, 위의 토론 내용중에는 pyrasis님의 의견에 동의하는 편입니다.

----
I paint objects as I think them, not as I see them.
atie's minipage

익명 사용자의 이미지

소비자들은 독과점을 원하지 않습니다. 소비자들이 원하는 것은 좋은 제품을 저렴한 가격에 구입하는 것이죠.

MS가 운영체제, 중요 애플리케이션 시장을 장악하면서 제품 가격이 꾸준히 오르고 있는데 이것은 소비자에게는 일종의 압박이면서 강제라고 생각합니다(우리나라나 중국은 복제가 일상이라 그런 부담이 없겠지만... -.-;; ). 대부분의 소비자는 소프트웨어 산업을 기존 산업과 별다르게 보지 않기 때문에 하드웨어 가격은 점점 내려가는데 소프트웨어 가격은 계속 오르는 것을 이해할 수 없을 것입니다.

결국 공개 표준을 따르든, 독과점의 강제적인 표준을 따르든 간에 이런 폐해를 먼저 줄여줄 수 있는 기술을 대부분의 소비자가 바라는 것 같습니다. 현실적으로는 두 기술 다 아직까지는 그런 영향력을 발휘하지는 못 한 것 같습니다. 소비자들은 구경만 하다 목표를 먼저 달성하는 쪽을 선택하지 않을까요?

(써놓고 보니 좀 암울한 것 같군요. :( )

방준영의 이미지

galien wrote:
방준영 wrote:
닷넷 애플리케이션의 스크린샷이 이 토론과 무슨 상관이죠? 토론 물 흐리려고 일부러 그러는 것 같아서 보기가 좋지 않군요.

애초에 이 쓰레드는 모노의 미래에 대해서 토론하는 것 아니었나요.
물론 표준 비표준에 대해서 말하고 싶어하시는 방준영씨의 마음은
이해합니다만,


저는 표준, 비표준을 따질 필요가 없다는 얘길 하고 있었는데... MS 것을 쓰지 말아야 한다는 주장으로 MS 것이 비표준이라서라는 이유를 제시하는데, 그 반대쪽에 서있는 자바나 리눅스도 비표준이기는 매한가집니다. 표준, 비표준 가지고 사용 여부를 결정하는 것은 말이 되지 않습니다.

Quote:
표준과 비표준, 마소의 클론이 될 것이냐, 마소의 새로운 도구를 흡수할
것이냐는 결국 어찌보면 신념에 가까운 얘기이고 사실과 허구에서는
약간 거리가 있는 정책, 나아가야 할 바에 대한 이야기입니다.

두분(혹은 네분)의 토론이 참 많은 생각할 거리를 던져주고,
무지했던 사실에대해 깨우쳐주셔서 감사합니다만, 그 중 몇 분은
상대방을 이해(설득이라기보다는)시키지 못하는 좌절감에
감정적으로 흐르지 않기를 바랍니다.

리눅스 유저라고 해서 신념이 같으란 법은 없으니, 서로 다름을
확인하고도 공존할 수 있지 않을까요.

갑자기 emacs 동료가 순식간에 철천지 원수로 변하는
유머가 생각나는 군요.


저는 감정적으로 흐르지 않기를 바란다는 얘기를 KLDP에서 끊임없이 MS를 비방하고 FUD를 유포해온 몇몇 분들에게 하고 싶습니다. MS가 개인적으로 싫거나 좋을 수는 있지만, 불합리한 이유를 들면서 감정적으로 MS의 기술을 깎아내리는 것은 결국 리눅스/유닉스 사용자들을 1970년대 낡은 기술에 머물러 있게 하는 것 밖에 되지 않습니다.

그리고 모노에 대응할 만한 기술이 리눅스에 이미 있었다면 모노가 이슈가 될 리가 없습니다. 그렇지 않나요? 모노의 대안으로 자바를 얘기하는데, 자바도 모노와 아주 똑같은 문제점이 있는데 그 얘긴 쏙 빼고 모노의 단점만 부각시키면 공정한 주장이 아니죠. 그래서 결국 모노가 안된다면 대안이 뭐냐는 것입니다. 모노를 반대하는 분들은 대안을 이야기하지 못합니다.

feanor의 이미지

방준영 wrote:
그리고 모노에 대응할 만한 기술이 리눅스에 이미 있었다면 모노가 이슈가 될 리가 없습니다. 그렇지 않나요? 모노의 대안으로 자바를 얘기하는데, 자바도 모노와 아주 똑같은 문제점이 있는데 그 얘긴 쏙 빼고 모노의 단점만 부각시키면 공정한 주장이 아니죠. 그래서 결국 모노가 안된다면 대안이 뭐냐는 것입니다. 모노를 반대하는 분들은 대안을 이야기하지 못합니다.

PyGTK로 짠 프로그램이 많습니까, GTK#으로 짠 프로그램이 많습니까? 직접 확인해 보세요. gnomefiles.org 같은 곳에서 말이죠. 저는 이것이면 대답이 되었다고 생각합니다.

--feanor

fender의 이미지

방준영 wrote:
저는 감정적으로 흐르지 않기를 바란다는 얘기를 KLDP에서 끊임없이 MS를 비방하고 FUD를 유포해온 몇몇 분들에게 하고 싶습니다. MS가 개인적으로 싫거나 좋을 수는 있지만, 불합리한 이유를 들면서 감정적으로 MS의 기술을 깎아내리는 것은 결국 리눅스/유닉스 사용자들을 1970년대 낡은 기술에 머물러 있게 하는 것 밖에 되지 않습니다.

그리고 모노에 대응할 만한 기술이 리눅스에 이미 있었다면 모노가 이슈가 될 리가 없습니다. 그렇지 않나요? 모노의 대안으로 자바를 얘기하는데, 자바도 모노와 아주 똑같은 문제점이 있는데 그 얘긴 쏙 빼고 모노의 단점만 부각시키면 공정한 주장이 아니죠. 그래서 결국 모노가 안된다면 대안이 뭐냐는 것입니다. 모노를 반대하는 분들은 대안을 이야기하지 못합니다.


FUD는 명확한 근거 없이 상대 기술에 대한 불신을 퍼뜨리는 행동이고, 최소한 저는 제가 왜 모노가 비표준 기술을 그대로 베끼는게 위험하다고 생각하는지 논리적으로 밝혔다고 생각합니다.

그리고 재차 강조하지만 전 모노의 대안이 GCJ나 썬의 자바라고 생각하지도 않고 이 쓰레드에서 그런 주장을 한 적도 없습니다.

애초에 모노가 주목받게 된 것에는 여러 이유가 있지만, 대체적으로 특히 최근에 대학에서 자바와 같은 고급언어를 주로 가르치기 때문에 이러한 학교를 졸업한 신세대 프로그래머들을 리눅스 쪽으로 흡수해보자는 취지도 있고, 무엇보다 MS 진영과는 달리 리눅스 쪽에는 어떤 표준화된 타입 시스템이나 여러 언어가 공통으로 사용할 수 있는 라이브러리, 인터페이스가 부족하다는 점이 모노가 그 대안으로 떠오른 큰 이유입니다.

개인적으로 그런 주장의 타당성은 인정하지만 과연 그게 지금 당장 MS.NET을 1:1로 베끼거나 자바냐 닷넷이냐 양자택일을 강요할 정도로 시급한 문제라고 생각하지 않습니다. 왜냐하면 이러한 주장과는 반대로 리눅스나 오픈소스의 점유율은 계속 증가해왔고 지금도 리눅스 프로그래머가 부족하거나 GTK/QT 응용프로그램이 없어서 윈도우즈와 경쟁이 안되는 상황이 아니기 때문입니다. 제 생각에 MS.NET과 자바의 싸움은 앞으로 1년 사이에 어느 방향으로든 결정이 날 것으로 봅니다. 이미 GTK의 경우 파이썬, C, C++, 자바, C# 등 수많은 언어의 바인딩이 존재하고 자바나 닷넷 코어 플랫폼이 제공하는 라이브러리는 대부분 어떤 형태로든 구현되어 있습니다.

그렇다면 지금 필요한 건 지금 처럼 꾸준히 오픈소스의 입지를 강화하면서 썬의 자바나 MS의 닷넷과 비교할 만한 오픈소스 플랫폼을 생각하거나 아니면 자바나 닷넷과 관련한 비표준, 독점 이슈들이 어느 정도 정리 될 때까지 기다려도 늦지 않다고 보는 입장입니다.

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

youlsa의 이미지

표준이나 뭐 그런 문제들이 어떻게 될지, MS가 모노를 어떻게 조치(?)할지 그런건 사실 저같은 개발자에게는 별 문제가 될거 같지는 않습니다.

중요한건 윈도우 프로그래머들에게 리눅스를 비롯한 오픈소스 프로그래밍 환경에서도 자기들이 알고 있는 C#같은 것들이 잘 돌아간다는걸 알게 해서 어떤 계기를 만들어 줄수 있다는 사실만으로도 모노의 존재 의의는 충분하다고 생각합니다.

사실 윈도우 플랫폼에서 Visual Studio등으로 작업하던 C/C++/C# 프로그래머에게 "리눅스에서는 gcc에 vi, emacs, gdb, etags등등으로 이렇게 편리하게 작업할수 있어"라고 하면 거품 뭅니다. 지금까지 써오던 환경과 언어도 다른데다가 툴들도 완전히 다르니 뭔가 하려고 해도 엄두가 안나지 않겠습니까. 최소한 C#이 잘 돌아간다는 사실만 알더라도 마치 지옥에서 부처 만난 기분이겠죠.

만약 라이센스 문제로 .NET API들을 사용하지 못하게 되더라도 크로스 플랫폼에서 잘 돌아가는 CLR과 그 위에서 잘 동작하는 C# 개발환경을 가진다는 것만 해도 오픈소스 진영에는 상당한 힘이 된다고 생각합니다.

오픈소스 진영의 특성상 모노도 "just one of them"일 뿐입니다. 앞으로 시간이 갈수록 커뮤니티에서 자연적으로 검증이 되어 효용성이 있다면 계속 발전해 나갈 것이고 아니라면 쇠퇴의 길을 걷겠죠. 그만큼 거칠고 냉혹한 세계죠, 오픈소스의 세계는... ^^

=-=-=-=-=-=-=-=-=
http://youlsa.com

logout의 이미지

일단 리눅스도 이제는 윈도우즈 데스크탑 시장을 잠식해 가야하는 상황에 접어든 것은 사실입니다. MS가 리눅스를 이제는 위협으로 인식하고 있다는 사실은 이제 공공연한 상식이 되었습니다.

보통 데스크탑 환경을 얘기할 때 우리는 사용자들이 리눅스를 쓰느냐 쓰지 않느냐에 관심을 많이 가집니다. 그리고는 아무리 리눅스가 기능이 좋더라도 일반 사용자들은 널리 쓰이고 손에 익은 윈도우즈를 쓰지 리눅스를 쓰지 않는다는 현실에 직면하게 됩니다. 소프트웨어 시장에서 네트워크 효과와 거기에서 비롯되는 과도한 스위칭 비용은 후발 주자에게는 극복하기 어려운 진입장벽인 것이 사실입니다.

그러나 이것보다 더욱 문제가 되는 것은 개발자들의 스위칭 비용입니다. 현 상황에서 윈도우즈 개발자가 리눅스용 어플을 개발하려면 결국 KDE나 Gnome 어플을 개발할 수 밖에 없고, 이는 곧 QT나 GTK+부터 새로 배워야 한다는 것을 의미합니다. 사실, 이런 상황에서 윈도우즈 개발자들이 리눅스로 플랫폼을 바꾼다는 것은 상상하기 어렵습니다.

모노는 이런 상황에서 윈도우즈 개발자들을 리눅스로 끌어들일 수 있는 가능성을 보여줍니다. 적어도 윈도우즈에서 MS.NET 어플 개발자라면 모노 덕분에 자신의 어플을 Gnome 환경으로 포팅하는 것을 심각하게 고려해 보게 될겁니다.

여기서 하나 또 생각해 볼 것은 윈도우즈 개발자들의 엄청난 숫자입니다. 상식적으로, 윈도우즈 개발자 10명 중 1명, 아니 100명중 한 명만 자신의 어플을 모노에 포팅한다고 하더라도 이 숫자는 아마 상당한 수준이 될 것이고 이는 임계점을 넘어서는 모노 개발자 커뮤너티의 형성으로 이어지게 되어 있습니다.

일단 여기까지만 모노가 성공적으로 자리를 잡는다면 그 이후로는 MS가 적으로 돌아서서 MS.NET의 표준을 바꾸어 나가더라도 별 문제가 없습니다. 그 때쯤이면 모노 사용자 커뮤너티가 자신들의 표준을 fork 해버리면 그만입니다. 자바의 경우는 썬이 적절한 선에서 자바에 대한 제어권과 자유로운 표준 개발 사이의 균형을 잘(?) 유지해 오고 있지만 자바 역시 썬이 지나치게 자바에 대한 제어권에 집착했다면 자바 개발자 커뮤너티에서 분명히 자바 컴파일러부터 완전히 새로 만들겠다는 얘기가 나왔을 겁니다. 한 때 Lignux라는 단어에 열받아서 gcc를 버리고 새 컴파일러를 만들겠다고 으름장을 놓는 저력이 있는 곳이 오픈 소스 개발자 커뮤너티입니다. 일단 임계점을 넘어 확산된 오픈 소스 플랫폼은 스스로 표준을 만들고 진화해 나갈 수 있는 저력이 충분합니다. 게다가, 윈도우즈 개발자 역시 MS가 주도하는 소위 패러다임 쉬프트를 항상 따라가야 하는데 상당한 불만을 갖고 있는 경우가 많습니다.

그런 의미에서 모노는 항상 MS.NET의 API를 쫓아가야하는 운명에 처해 있다고 보기 힘듭니다. 일단 최소 수준의 임계점까지만 모노가 확산되고 나면 그 이후에는 오히려 모노의 표준을 MS가 구현해야 하는 상황이 전개될 수도 있습니다. 중요한 것은 윈도우즈 개발자들이 모노용으로도 어플을 내놓는 것을 자연스럽게 생각하는 변화를 유도해 내는 것입니다.

리눅스 데스크탑은 결정적으로 윈도우즈에 비해 가격이 싸다는 장점이 있습니다. 아무리 MS가 윈도우즈의 가격을 내려도 공짜로 윈도우즈를 출시할 수는 없습니다. 게다가, 기업 환경처럼 오피스와 여러가지 솔루션들이 번들링되면서 가격이 천정부지로 솟는 경우는 비슷한 기능을 제공할 수 있는 경우 리눅스 데스크탑이 대안으로 쉽게 자리잡을 수 있습니다. 만약, Gnome 데스크탑이 모노덕택에 어플리케이션 공급의 측면에서도 윈도우즈용 어플을 고스란히 받아들여 돌릴 수 있다면 기업 환경에서는 똑같은 어플을 돌릴 수 있는데 굳이 돈을 더 주고 비싼 윈도우즈를 구매할 필요가 없게 됩니다. 이런 상황이 사실 제대로 된 리눅스 데스크탑 환경의 도래가 아닐까요?

그런 이유로 모노가 MS.NET을 "쫓아가는" 방식은 위험해 보여도 일단 힘을 실어줄 필요가 많다고 봅니다. 위험이 있어 보이지만 그만큼 성공했을때 예상되는 이득이 크며 윈도우즈 개발자들을 쉽게 리눅스 데스크탑 환경으로 이전시킬 있는 잠재력을 갖고 있습니다. 어차피 지금 상황에서 Gnome 환경이 윈도우즈로 포팅될 가능성도 없고, Gnome 데스크탑이 윈도우즈로 포팅되더라도 윈도우즈 개발자들은 Gnome 프로그래밍에는 관심이 없을 것이라는 상황을 고려한다면 모노가 거꾸로 윈도우즈를 따라가는 것이 적절한 접근 방법이라고 봅니다.

조금은 상황이 다르지만 애플의 매킨토시에서 현재 이러한 상황이 실제로 발생하고 있습니다. 맥의 오에스텐은 아시다시피 기본적으로 BSD 입니다. 여기에 애플은 아쿠아 데스크탑, 코코아 API 등등을 집어넣어 자신들만의 오에스를 만들었습니다. 물론, 맥 오에스텐 전용 어플은 코코아나 카본 API가 리눅스나 다른 BSD계열 유닉스에 포팅되어 있지 않기 때문에 다른 플랫폼에서 돌릴 수 없습니다.

그러나 애플이 오픈소스 환경에 free-riding해서 얻은 이득은 큽니다. 그중에서 가장 중요한 이득은 오픈 소스 어플의 오에스 텐 환경으로의 유입입니다. 어차피 이들 오픈 소스 어플들은 유닉스 기반이니 재컴파일 작업으로 오에스텐으로의 포팅이 끝이 납니다. 그리고 많은 경우 이러한 어플들 중의 상당수가 command-line 기반 오픈소스 어플에 코코아 그래픽 유저 인터페이스 frontend를 입혀서 내놓습니다. 이 덕분에 애플의 오에스 텐은 짧은 기간 동안에 많은 수의 어플리케이션을 확보할 수 있게 되었습니다. 오픈 소스 진영의 그 누구도 어플 개발시 오에스 텐 전용으로의 포팅을 심각하게 고려하지 않고 있는데도 말입니다.

마찬가지 상황이 모노에서도 발생할 개연성이 높습니다. 오에스 텐의 경우야 리눅스 역시 마이너 플랫폼이다 보니 소수의 리눅스 사용자의 오에스 텐으로의 유입이 맥 플랫폼의 입장에서는 큰 영향이 없습니다만 윈도우즈 사용자가 Gnome 환경을 윈도우즈 환경과 비슷하다고 여기게 된다면 그 여파는 상당할 것입니다. 모노가 지향하고 있는 윈도우즈 개발자의 유입은 그래서 관심있게 지켜볼 필요가 있습니다. 모노는 언제까지나 MS의 뒷걸음만 따라가야 하는 숙명을 타고 나지 않았기 때문입니다.

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

방준영의 이미지

fender wrote:
FUD는 명확한 근거 없이 상대 기술에 대한 불신을 퍼뜨리는 행동이고, 최소한 저는 제가 왜 모노가 비표준 기술을 그대로 베끼는게 위험하다고 생각하는지 논리적으로 밝혔다고 생각합니다.

리눅스 조차도 유닉스라는 비표준 기술을 베꼈죠. 그런데 정작 고소는 MS가 모노에게 한 것이 아니라 유닉스가 리눅스한테였지 않습니까. fender님 말씀이라면 아예 리눅스도 쓰지 말았어야 했을 듯 합니다.

그리고 MS가 API 제정을 좌지우지하기 때문에 위험하다고도 하는데, 사실 유닉스 세계에서는 그보다 더 황당한 일이 계속 일어났습니다. API가 갑자기 망하거나 개발이 중단되어 버리는 거죠. Gtk와 Qt 이전에 있던 온갖 종류의 툴킷들 지금 다 어디로 갔나요.

적어도 MS의 것을 따른다면 최소한 앞으로 10년간은 마음놓고 개발할 수 있습니다.

Quote:
그리고 재차 강조하지만 전 모노의 대안이 GCJ나 썬의 자바라고 생각하지도 않고 이 쓰레드에서 그런 주장을 한 적도 없습니다.

애초에 모노가 주목받게 된 것에는 여러 이유가 있지만, 대체적으로 특히 최근에 대학에서 자바와 같은 고급언어를 주로 가르치기 때문에 이러한 학교를 졸업한 신세대 프로그래머들을 리눅스 쪽으로 흡수해보자는 취지도 있고, 무엇보다 MS 진영과는 달리 리눅스 쪽에는 어떤 표준화된 타입 시스템이나 여러 언어가 공통으로 사용할 수 있는 라이브러리, 인터페이스가 부족하다는 점이 모노가 그 대안으로 떠오른 큰 이유입니다.

개인적으로 그런 주장의 타당성은 인정하지만 과연 그게 지금 당장 MS.NET을 1:1로 베끼거나 자바냐 닷넷이냐 양자택일을 강요할 정도로 시급한 문제라고 생각하지 않습니다. 왜냐하면 이러한 주장과는 반대로 리눅스나 오픈소스의 점유율은 계속 증가해왔고 지금도 리눅스 프로그래머가 부족하거나 GTK/QT 응용프로그램이 없어서 윈도우즈와 경쟁이 안되는 상황이 아니기 때문입니다. 제 생각에 MS.NET과 자바의 싸움은 앞으로 1년 사이에 어느 방향으로든 결정이 날 것으로 봅니다. 이미 GTK의 경우 파이썬, C, C++, 자바, C# 등 수많은 언어의 바인딩이 존재하고 자바나 닷넷 코어 플랫폼이 제공하는 라이브러리는 대부분 어떤 형태로든 구현되어 있습니다.


Gtk/Qt의 애플리케이션이 수는 많을지 몰라도 쓸만한 것은 거의 없다고 할 수 있을 정도로 적습니다. 위에서 말씀드린 이유대로 기업에서는 Gtk/Qt 플랫폼을 거의 완전히 무시하고 있는 상황이구요. 쓰는 사람도 별로 없는데 언제 망할지도 모르겠고 기능은 불충분하고 개발 환경은 열악하고... 결국 모노의 대안으로 Gtk/Qt를 생각한다면 현상황에서 달라질 건 없습니다.
fender의 이미지

방준영 wrote:
그리고 MS가 API 제정을 좌지우지하기 때문에 위험하다고도 하는데, 사실 유닉스 세계에서는 그보다 더 황당한 일이 계속 일어났습니다. API가 갑자기 망하거나 개발이 중단되어 버리는 거죠. Gtk와 Qt 이전에 있던 온갖 종류의 툴킷들 지금 다 어디로 갔나요.

적어도 MS의 것을 따른다면 최소한 앞으로 10년간은 마음놓고 개발할 수 있습니다.


차라리 MS가 망해서 닷넷을 개발할 여력이 없다면 그 기술을 베낀다고 누가 뭐라고 하겠습니까? 제가 중시하는 건 사용자를 얼마나 끌어들이느냐보다는 오픈소스라면 오픈소스 사용자와 개발자가 직접 발전 방향을 정하는 것이 무엇보다 중요하다고 봅니다. 이 부분은 저와 준영님의 근본적인 시각차이라고 생각합니다.

방준영 wrote:
Gtk/Qt의 애플리케이션이 수는 많을지 몰라도 쓸만한 것은 거의 없다고 할 수 있을 정도로 적습니다. 위에서 말씀드린 이유대로 기업에서는 Gtk/Qt 플랫폼을 거의 완전히 무시하고 있는 상황이구요. 쓰는 사람도 별로 없는데 언제 망할지도 모르겠고 기능은 불충분하고 개발 환경은 열악하고... 결국 모노의 대안으로 Gtk/Qt를 생각한다면 현상황에서 달라질 건 없습니다.

일단 기업에서 Gtk/Qt가 각광받지 못하는 이유는 응용프로그램 부족 보다는 데스크탑으로서 리눅스가 아직 본궤도에 오르지 못했기 때문입니다. 하지만 그런 움직임은 분명 최근 2-3년 사이에 확실히 긍정적인 방향으로 변화하고 있습니다.

오픈소스가 중요하다, 아니면 시장점유율이 중요하다, 혹은 GTK/QT가 발전하고 있다 아니다는 보는 사람의 시각에 따라 크게 달라질 수 있는 부분입니다. 여기에 대한 이야기는 어떤 구체적인 근거가 없다면 더 이상 어느 쪽으로 의견이 좁혀지지 않을 것 같습니다.

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

LispM의 이미지

표준이니 비표준이니 이런 것은 별 의미가 없다고 생각합니다. 표준이 아닌 사실상의 표준은 공식적으로 표준화를 할 때 유리한 입장이 되기 때문이죠.

사실상의 표준은 영향력인데, 소프트웨어의 경우 사용자의 수가 곧 영향력이 될 수 있기 때문에 방준영님의 의견에 한표 던집니다. (MS가 그랬고, Google 그렇고, Java가 그랬고 ...)

소프트웨어 역사상 기술적으로 우위에 있던 것들이 흔적도 없이 사라진 예는 아주 많습니다. 사용자 층이 엷었기 때문이죠. 때문에 어쩌면 문제가 되지 않는 한 MS건 Mac이건 누구의 기술이건 돌아가게 하는 것이 살아남는 데 유리할 지도 모릅니다.

또 다른 Worse is better의 예가 되지 않을까요?

http://lisp.or.kr http://lisp.kldp.org - 한국 리습 사용자 모임

익명 사용자의 이미지

방준영 wrote:
fender wrote:
방준영 wrote:
fender wrote:
과거 오픈소스에 적대적 태도를 보였던 거대 독점기업의 비표준 API를 1 :1로 무작정 베끼는 것

전세계 98% 사용자/개발자들이 사용하는 API가 "비표준"이라면, "표준"이란 과연 무엇인지 정의를 부탁드립니다. 자바나 유닉스 API는 표준인가요?

그리고 오픈소스에 적대적 태도를 보였단 얘기는 어폐가 있는 내용입니다. MS가 적대적인 것은 오픈소스중의 GPL이지 나머지 라이센스에 대해서는 별 불만 없습니다. 오픈소스를 지지하는 사람들중에서도 MS와 비슷한 이유로 GPL을 싫어하는 사람들이 많이 있습니다.


여기서 '표준'이란 MS와 같은 특정 기업이 마음대로 개발하고 관리할 수 없는 ECMA와 같은 표준화 기구에서 관리되는 기술을 말합니다.

그렇다면 자바와 리눅스 API(유닉스 API에 대한 독자적 확장으로서)는 표준이 아닌 것은 분명하군요. fender님이 선호하시는 표준이란 과연 무엇입니까? 저는 표준, 비표준을 구분한다는 것 자체에 찬성하지 않기에 이런 질문을 드리는 것입니다.

Quote:
독점 기술의 API를 그대로 베껴서 만든 플랫폼, 라이브러리를 오픈소스 커뮤니티에서 받아들이는 경우 무엇보다 해당 기술의 소유권을 가진 기업에 오픈소스 커뮤니티 전체가 끌려다닐 수 있다는 비판이 많습니다. 하지만 해당 기술이 독립된 기관에서 관리되고 기술에 대한 명세 및 API를 결정하는데 참여할 수 있다면 그런 위험이 적기 때문입니다.

아주 똑같은 얘기를 자바에 대해서도 할 수 있는데 어찌해서 fender님은 항상 자바에 편향된 주장을 되풀이 하시는지...?

Quote:
말씀하신 사용하는 사람이 많아서 사실상의 표준으로 인정된 것은 'de facto standard'라고 하지만 과연 MS.NET과 모노의 닷넷 구현이 차이가 있을 때 어느 쪽이 업계에서 '사실상의 표준'으로 인정 받을지는 의심의 여지도 없습니다.

이런 비현실적인 가정은 그만해 주시면 감사하겠습니다. AMD가 인텔 CPU와 호환이 안되면, 당연히 안팔리겠죠?

Quote:
그리고 '많이 쓰면 표준이고 따라서 문제가 없다'라는 걸 그대로 받아들인다면 모질라나 오픈오피스나 리눅스나 다 의미가 없는 해커들의 자기만족이 아닐까 싶습니다. 중요한 건 IE, MS 오피스, 윈도우즈는 특정 기업이 독점적으로 개발하고 모질라 등은 오픈소스로 누구나 개발하고 의견을 제시할 수 있다는 점입니다. 그게 바로 오픈소스의 핵심이고 여기 오시는 분들은 바로 그런 오픈소스의 장점을 가치있게 보시는 분들이 아닌지요...

소프트웨어의 가치는 그 소프트웨어를 사용하는 사용자의 수에 정확히 비례합니다. 똑같이 만든 프로그램이 하나는 100명이 쓰고 하나는 100만명이 쓴다면 어느쪽이 더 가치있는 소프트웨어인지 명확하지 않습니까. 오픈소스가 발전하려면 더 이상 자기만족 수준에 머물러 있어서는 안됩니다. 개발자 자신이 원하는 소프트웨어보다 사용자가 원하는 소프트웨어를 만들어야죠.
좀 다른 이야기를 할께요...
재가 생각하기에 재미있는 사실은 C#의 결과물들이 적어도 Linux에서 돌기 시작했다는 점입니다. 그리고 그 결과물이 웹 기반이냐 OS기반이냐의 문제는 제쳐두고서도 이제는 Language자체가 Write One, Run Anyway(맞나요?)를 외치고 있다라는 사실입니다.
이것만 놓고 본다면 Linux와 Windows의 경계는 더 이상 의미가 없다고 봅니다.

단 위에서 말했듯이 API가 문제가 됩니다만... 제 생각에는 표준은 표준이고 비표준은 비표준입니다. 아무리 MS가 비표준 확장을 통한 API를 사용한다고 하더라도 그것 하나 때문에 Mono가 죽을 것이라고 생각한다면 웃기죠^^ 또한 비표준 확장은 Microsoft가 적어도 독과점이라는 틀을 벗어나기 위해서는 최소한의 공개를 할것이고 이것은 어느 누군가가 더 좋은 API나 아님 그냥 이식을 통해서 사용될 수 있다고 봅니다. 이것은 자바도 마찬가지 아닌가요?

제 생각에는 Mono가 아직까지는 MS에 의해서 이용되거나 어떠한 이득을 보았다고 생각하지는 않습니다. 또한 앞으로도 그럴 것이구요.

하지만 Java는 약간 다르다고 생각합니다. Java는 Sun에 의해 기본적인 API및 확장 API가 관리됩니다. 이것이 좋다 나쁘다라는 것을 떠나서 기술적인 종속이라는 것입니다. 이런 Language의 관리 모델이 나쁘다라는 것은 아니지만 또한 좋다라는 것도 아닙니다. 단지 우리가 한번의 클래임은 있었지만 참고 오고 있는 거죠.

즉 Java의 경우는 Sun에 의해서 좌지우지 되고 있다라는 것입니다.

그럼 .NET의 경우는요? 물론 ECMA에 표준을 제안한 것은 Microsoft겠지만... 적어도 그들의 영향력은 Windows로 국한될 것이라는 생각입니다. 만약 Linux가 .NET Framework을 기반으로 한다면 이야기는 달라지겠지만 말입니다.(우스운 이야기죠...)

즉 제 생각에는 결국 Mono와 Microsoft의 .NET은 별게의 Project로 진행하게 될 것이라는 것입니다. Microsoft가 Sun처럼 License에 대한 권리를 주장하지 않은 이상은 Linux와 Windows는 자체 확장 API를 통한 발전은 피할 수 없다라는 것이죠.

그 첫번째 근거는 OpenSource의 대표가 바로 Linux이고 Commercial Product의 대표가 바로 Window이기 때문입니다. 한쪽은 기술의 공개를 목적으로 다른 한쪽은 기술의 판매를 목적으로 하기 때문에 Mono가 상업적인 용도로 사용되지 않는다고 하더라도 크게 문제가 될 것은 없다라는 것이죠. 또한 Microsoft가 자기네들만이 Selling하거나 바꿀 수 있는 License를 건 API를 만들어 낸다고 하더라도 Open Source의 수많은 인력은 가만히 있지 않을 것이라는 것입니다. 자신들의 고유한 API를 결국 만들 것이라는 것이죠...
즉 확장 API가 있든 없든 문제가 되지 않는다는 것이죠. 단지 시간만이 문제라는...

두번째는 표준입니다. ECMA에 제안된 C#및 CLR등의 표준은 적어도 시스템에 종속적이지는 않을 것입니다. 이것을 반대로 말하면 시스템에 종속적인 부분은 직접 만들어야 한다는 것이고 이것은 비표준 확장 API를 만들라는 이야기와 같습니다. Java를 예로 들면 Swing이나 그 외의 여러가지 GUI도구들의 Performance가 OS에 너무 독립적이어서 속도가 나지 않았습니다. 즉 표준의 범주를 벗어나지 않기 위해서의 노력의 결과가 그것였죠. 이것은 Java가 웹 서비스용으로 그 용도를 국한하게 만드는 것이었는데, Mono나 .NET에서의 웹이란 C#및 CLI, CLR의 사용의 일부일 뿐입니다. 즉 GUI의 중요성도 강조하고 있다는 이야기라고 생각합니다. 이것을 생각하면 역시 Linux와 Windows는 그 구현자체가 다르기 때문에 GUI의 Implemetation을 최대한 독립적으로 한다고 하더라도 어느 순간에는 서로에게 독립적인 GUI가 나온다는 이야기죠.(나중에 Wrapper클래스가 나와서 이들을 한번에 덮는다는 난중에 이야기로 치부합시다.)

세번째는 개발과정 자체의 문제입니다. 한쪽은 Open Source이고 다른 한쪽은 Commercial Product입니다. 공짜를 좋아하는 개발자 입장에서 어느 쪽에 Platform에서 자신의 프로그램을 만드는 것을 더 좋아할까요?

네번쨰는 개발자 자신들의 요구입니다. 표준보다 더 낳은 것이 있다면 그것이 표준이 되는 것입니다.

분명한 이야기지만 칼자루를 들고 있는 것은 MS라고 생각합니다. 하지만 그 이상의 생각해야 할 것은 개발자들이 언제까지나 MS의 편을 들것이냐 입니다. 이렇게 구미를 당기는 언어를 만든 것은 MS이지만, 그것을 ECMA에 표준화 한 것도 MS이기 때문입니다.

sDH8988L의 이미지

dyanos79 wrote:

...
제 생각에는 Mono가 아직까지는 MS에 의해서 이용되거나 어떠한 이득을 보았다고 생각하지는 않습니다. 또한 앞으로도 그럴 것이구요.
...

사실, Open Source 개발자들이 Mono에 대해서 가장 걱정하는 부분이 나중에 MS가 Mono에 대해서 딴지를 걸지 않을까 하는 점입니다...

그런데, 무슨 근거로 MS에 의하여 앞으로도 이용되지 않을 것이라고 확신하시는 지요...

만일, MS가 Mono를 이용하지 않는다는 전제만 있다면, 사람들이 왜 Mono의 미래에 대해서 걱정하겠습니까... 그런 전제가 있다면, Mono의 정체성에 대해서 왈가왈부하는 사람들은 있을 지 몰라고 지금과 같은 토론은 애초에 생겨나지 않겠죠...

fender의 이미지

dyanos79 wrote:
단 위에서 말했듯이 API가 문제가 됩니다만... 제 생각에는 표준은 표준이고 비표준은 비표준입니다. 아무리 MS가 비표준 확장을 통한 API를 사용한다고 하더라도 그것 하나 때문에 Mono가 죽을 것이라고 생각한다면 웃기죠^^ 또한 비표준 확장은 Microsoft가 적어도 독과점이라는 틀을 벗어나기 위해서는 최소한의 공개를 할것이고 이것은 어느 누군가가 더 좋은 API나 아님 그냥 이식을 통해서 사용될 수 있다고 봅니다. 이것은 자바도 마찬가지 아닌가요?

자바의 경우 공식적으로 발표되는 "모든" API와 JVM 스펙, 자바 언어 자체에 대한 명세는 JCP(Java Community Process)에 의해 공개적으로 관리되고 있습니다. MS.NET의 경우 C#과 콘솔 어플리케이션을 만들 수 있을 정도의 "일부" API가 ECMA에 제출되었을 뿐입니다.

어쨌든 중요한 점은 비표준 API를 통한 확장의 위험은 MS가 비표준 API를 공개하지 않을까봐서가 아니라 MS.NET과의 호환성을 목표로 하는 한 영원히 따라하기 게임을 벌여야 한다는데 있습니다.

dyanos79 wrote:
하지만 Java는 약간 다르다고 생각합니다. Java는 Sun에 의해 기본적인 API및 확장 API가 관리됩니다. 이것이 좋다 나쁘다라는 것을 떠나서 기술적인 종속이라는 것입니다. 이런 Language의 관리 모델이 나쁘다라는 것은 아니지만 또한 좋다라는 것도 아닙니다. 단지 우리가 한번의 클래임은 있었지만 참고 오고 있는 거죠.

즉 Java의 경우는 Sun에 의해서 좌지우지 되고 있다라는 것입니다.


JCP에는 자바에 관심있는 단체 및 개인이 자유롭게 참여할 수 있습니다. 대표적으로 아파치 재단이나 오라클, IBM 등이 JCP 회원입니다. JCP에서 썬의 영향력이 없다거나 JCP가 공인된 표준화 기구라고 주장하고 싶진 않지만 자바 언어는 썬 혼자서 좌지우지 한다는 주장은 분명 잘못된 것입니다.

dyanos79 wrote:
또한 Microsoft가 자기네들만이 Selling하거나 바꿀 수 있는 License를 건 API를 만들어 낸다고 하더라도 Open Source의 수많은 인력은 가만히 있지 않을 것이라는 것입니다. 자신들의 고유한 API를 결국 만들 것이라는 것이죠...
즉 확장 API가 있든 없든 문제가 되지 않는다는 것이죠. 단지 시간만이 문제라는...

오픈소스의 목표가 공짜 MS 플랫폼을 만드는 것이라면 문제는 없습니다만, 개인적으로 독점 기업에 의해 발전 방향이 좌우되는 오픈소스는 의미가 없다고 봅니다. 여기에 대해선 이미 위에서 수차례 언급이 되었기 때문에 길게 논의하지 않겠습니다.

dyanos79 wrote:
Java를 예로 들면 Swing이나 그 외의 여러가지 GUI도구들의 Performance가 OS에 너무 독립적이어서 속도가 나지 않았습니다. 즉 표준의 범주를 벗어나지 않기 위해서의 노력의 결과가 그것였죠. 이것은 Java가 웹 서비스용으로 그 용도를 국한하게 만드는 것이었는데, Mono나 .NET에서의 웹이란 C#및 CLI, CLR의 사용의 일부일 뿐입니다.

솔직히 윈도우즈에서 최신버전 자바 스윙/SWT와 WinForms가 그렇게 의미있는 성능차이가 난다고 생각하진 않습니다. 어쨌든 여기서 중요한 건 자바 vs 닷넷의 효용성이나 성능비교가 아닙니다. 꽤나 흥미로운 토론을 할 수 있는 주제지만 굳이 이 쪽으로 이야기를 이어가려면 별도의 글타래를 여는게 나을 것 같습니다.

dyanos79 wrote:
세번째는 개발과정 자체의 문제입니다. 한쪽은 Open Source이고 다른 한쪽은 Commercial Product입니다. 공짜를 좋아하는 개발자 입장에서 어느 쪽에 Platform에서 자신의 프로그램을 만드는 것을 더 좋아할까요?

저작권 측면에서 보면 자바나 닷넷이나 동일합니다. 모노가 MS.NET의 유일한 오픈소스 구현이지만 자바의 경우 오픈소스 구현은 Classpath/GCJ, Kaffe, SableVM, KissmeVM 등 훨씬 많고 비오픈소스 구현도 IBM, BEA 등의 제품이 있습니다.

결론적으로 정리해서,

(1) 저작권 측면에서 모노, GCJ/Classpath 등은 모두 GPL로 차이가 없습니다.
(2) Sun의 경우 자바와 관련된 모든 것이 표준화 기구는 아니지만 썬과 관련 없는 수많은 개인, 단체가 참여하는 JCP에 의해 관리 되고 있습니다. 반면 MS.NET은 ECMA라는 표준화 기구에 의해 관리 되지만 표준에 적용 받는 것은 C#과 플랫폼의 일부입니다.

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

creativeidler의 이미지

자바에 대한 몇 가지 편견에 대해

1. 자바는 썬 마음대로다.
fender님이 반박하셨듯 자바가 JCP로 넘어간지는 오래 되었습니다. 어떻게 보면 썬 참 불쌍하죠. 자바 만들어서 이렇게 널리 쓰이고 있는데 자바로 돈은 못 벌고 독점적 권리마저 JCP에 넘겨주었으니 말입니다. 물론 썬의 영향력이 가장 강하긴 하지만 그 점이 부정적으로 작용하는 경우는 없다고 볼 수 있죠.

2. 자바 GUI는 느리다.
느린 건 맞습니다. 근데 닷넷보다 느리진 않습니다. 잘 만든 스윙 애플리케이션 돌려보면 정말 느리다는 느낌 하나도 안 들 정도인 것도 많습니다. 닷넷으로 만든 것들 써보면 환장하게 만드는 것이 좀 있죠-_-

3. 자바 데스크탑은 가망 없다.
국내에 한해 맞는 얘깁니다. 미국의 경우 스윙으로된 상용 애플리케이션이 상당히 많습니다. 심지어 SI에서 C/S 기반도 자바로 만드는 기업이 많습니다. 국내의 모 오피스 업체는 자바로 오피스 만들어서 미국 관공서에도 납품하고 있죠. 오피스!를 자바로 만들어서 돌린단 말입니다!! 사실 오피스까지 갈 것도 없습니다. 거의 모든 자바 개발툴은 자바로 되어 있죠-_- 이거 느리다고 안 쓰는 개발자 아무도 없습니다. 비단 선택의 여지가 없어서만은 아닙니다.

현재 전 세계에서 가장 많은 개발자를 보유하고 있는 언어..뭐라고 생각하십니까? C#은 물론 아니겠죠? C도, C++도 아닙니다. 현재 자바가 17%가량, C, C++이 각각 16% 초반, C#은 1.6%입니다.

사실 본 주제랑은 큰 상관 없는 이야기인데 굳이 왜 하냐면-_- kldp를 비롯한 리눅스 공동체에서 자바의 가치를 너무 낮게 평가하는 경우를 많이 봐왔기 때문입니다. 분명 지금 자바는 엔터프라이즈 컴퓨팅에서 부동의 정상을 차지하고 있습니다. 닷넷의 점유율이 올라가는 것은 C++을 대체하고 있기 때문이지 자바를 대체하고 있기 때문이 아닙니다. 사실 이 쓰레드에선 닷넷과 모노 얘기만 나와야할 것 같은데 이상하게 자바에 대한 부당한 평가 절하가 나오는 것 같아서 자바 프로그래머로서 한 마디 해 봤습니다-_-

youlsa의 이미지

creativeidler wrote:
kldp를 비롯한 리눅스 공동체에서 자바의 가치를 너무 낮게 평가하는 경우를 많이 봐왔기 때문입니다.

자유소프트웨어 운동이나 오픈소스 소프트웨어 운동을 주도하는 사람들이 고슬링이나 썬의 행태를 체질적으로 싫어하기 때문이겠죠. 스톨만 아저씨야 원래 고슬링이 emacs 라이센스 팔아먹은거 때문에 철천지 원수니까 그럴수밖에 없겠구요, Eric Raymond의 인터뷰 기사나 책 (The Art of Unix Programming) 을 봐도 곳곳에 자바에 대한 의도적인 평가절하를 하고 있는걸 볼 수 있습니다. Python등과 비교하면서 은근히 비꼬죠. ^_^

=-=-=-=-=-=-=-=-=
http://youlsa.com

cjh의 이미지

Quote:
kldp를 비롯한 리눅스 공동체에서 자바의 가치를 너무 낮게 평가하는 경우를 많이 봐왔기 때문입니다.

자바가 얼마나 널리 쓰이는지는 사실 감이 안옵니다만 (저는 자바랑 별로 관련없는 분야에 종사하고 있어서...) 오픈 소스 커뮤니티에서 오픈 소스가 아닌걸 싫어하는건 당연하지 않을까요? ESR은 emacs/python등을 아주 좋아하니까 그렇다 치더라도... Sun을 특별히 싫어할 이유는 없을 듯 한데요. 자바라면 모르겠지만 OpenOffice라든가 여러가지 오픈 소스 유닉스 커뮤니티에 공헌한 바가 있으니...

--
익스펙토 페트로눔

creativeidler의 이미지

Quote:
자바가 얼마나 널리 쓰이는지는 사실 감이 안옵니다만 (저는 자바랑 별로 관련없는 분야에 종사하고 있어서...) 오픈 소스 커뮤니티에서 오픈 소스가 아닌걸 싫어하는건 당연하지 않을까요?

오픈 소스 커뮤니티에서 오픈 소스가 아닌 걸 싫어하는 것은 당연합니다만, 그게 자바를 싫어할 이유는 되지 못합니다. freshmeat.net에 등록된 프로젝트 중 자바 프로젝트는 C에 이어 두번째로 많습니다. 물론 이게 다 오픈 소스는 아니지만 OSI 인증 받은 라이센스가 상당히 많고 GPL도 많습니다. Apache Group, Open Symphony, codehaus, eclipse, java.net 처럼 고품질의 자바 컴포넌트들을 쏟아내주는 커뮤니티도 많고요. 엔터프라이즈 컴퓨팅에서 이처럼 오픈 소스가 많은 언어는 자바 밖에 없습니다.

사실 따지고보면 리눅스와 자바는 반 MS 진영의 두 기둥입니다. 이 둘이 친해진다면 엄청난 시너지 효과를 낼 수 있을 꺼라고 보기에 리눅스 진영에서 자바를 평가절하하는 것이 못내 안타깝습니다.

feanor의 이미지

creativeidler wrote:
오픈 소스 커뮤니티에서 오픈 소스가 아닌 걸 싫어하는 것은 당연합니다만, 그게 자바를 싫어할 이유는 되지 못합니다. freshmeat.net에 등록된 프로젝트 중 자바 프로젝트는 C에 이어 두번째로 많습니다. (etc)

물론 싫어할 이유가 됩니다. 시각의 차이입니다.

1) 썬의 자바는 오픈 소스가 아닙니다. (썬 커뮤니티 소스 라이센스가 OSI에 맞지 않을 뿐더러 소스만 볼 수 있다 뿐이지 "오픈 소스"스럽지 않다는 데에는 동의하시리라 믿습니다.)

2) 그런데 freshmeat.net 등등에 등록된 수많은 오픈 소스 자바 프로젝트들이 썬 자바가 아닌 카페나 GCJ에서 돌아가느냐? 하면 그렇지가 않습니다.

2번이 중요한데, 2번이 안 되는 이유는 카페나 GCJ가 부족한 면도 약간 있지만, 근본적으로 오픈 소스 자바 개발을 하는 사람들이 썬 자바 이외에는 "개무시를 하기 때문입니다" (강조 20번) 단 두 세줄 workaround를 넣어서 돌아가게 할 수 있는 예가 꽤 있습니다. 대부분의 자바 프로젝트는 썬 자바 이외의 런타임에 대해 전혀 테스트를 하려 하지 않습니다.

그래서 자바 그놈(Java GNOME)같은 매우 오픈 소스와 친한 프로젝트마저 데비안 메인에 들어가지 못하거나 하는 일이 생깁니다. 자바 그놈 문제가 아니라, 자바 그놈에서 쓰는 CORBA 구현이 썬 자바에서만 테스트가 되어서 자유로운 런타임에서 돌아갔다 안 돌아갔다 하기 때문입니다.

자바 런타임간의 호환성은 생각보다 문제가 많습니다. 1.3을 요구하는 자바 프로그램이 1.4에서 돌아가지 않는 경우도 있습니다. 그리고 대부분 자바 프로젝트의 태도는 "썬에서 나온 가장 최신 런타임 깔아라. 나머지는 테스트 안 한다 배째라"입니다. 이러니 반감이 생길 수밖에 없습니다.

매크로미디어사의 최신 플래시 포맷은 자유롭지 않은 소프트웨어를 깔아야만 볼 수 있다는 면에서 자유롭지 못한 플랫폼이고, 따라서 플래시를 활발하게 사용하는 오픈 소스 웹 프로젝트가 적은 것을 이해할 수 있습니다. (최근에 Laszlo가 오픈 소스로 풀리긴 했습니다만...)

마찬가지 이유에서, 자바는 자유롭지 못한 플랫폼이고, 따라서 자바를 활발하게 사용하는 오픈 소스 프로젝트를 자바 이외의 진영에서 꺼리는 것을 이해할 수 있습니다.

--feanor

fender의 이미지

참고로 지금은 Java-GNOME과 GCJ 모두 데비안에 들어가 있습니다. 사실 데비안과 젠투는 자바 지원이 꽤 괜찮은 배포판 중의 하나입니다.

어쨌든 말씀하신 대로 썬의 JDK/JRE는 오픈소스가 아니고, 썬이 오픈소스 진영에서 백안시 당하게 된 가장 큰 이유는 이제까지 자바의 오픈소스화에 대한 문제에 있어서 썬이 입장을 바꾸거나 불분명한 태도로 일관해 왔다는 점입니다. 그리고 초창기 자바가 등장했을 때 사람들의 기대감과는 달리 형편없는 위젯 지원과 느린 속도 등으로 첫인상이 매우 좋지 못하게 남았습니다. 그리고 상대적으로 C/C++을 배경으로 하는 오픈소스 개발자가 자바 언어에 대해 느끼는 반감도 무시할 수 없습니다.

이런 면을 볼 때 모노, ECMA, 그리고 C/C++ 개발자들이 친근감을 느낄 수 있게 하는 여러 장치들을 적절히 이용하는 MS의 뛰어난 마케팅 전략과 썬의 사실상 마케팅의 부재(솔직히 말하면 '삽질')가 맞물려 오늘과 같은 결과가 나왔다고 생각합니다.

자바의 미래를 위해선 썬이 자바를 오픈소스로 풀거나 IBM에 인수되는 것이 훨씬 낫다고 봅니다.

어쨌거나 썬의 삽질을 제외하면 저작권이나 대부분의 프로젝트가 오픈소스 JVM이 아닌 썬의 제품에 최적화 되어 있는 등의 문제는 MS.NET과 모노에도 그대로 적용되는 문제입니다. 다만 아직 표면화되지 않았을 뿐이라고 생각합니다. (참고로 여기에는 조금은 더 복잡한 문제가 걸려있습니다. 공식적으로 JVM 등의 스펙은 모두 공개적으로 관리되지만 이를 구현한 결과물에 '자바'라는 이름을 붙이기 위해선 특정한 자동화된 테스트를 통과해야 합니다. 특히 오픈소스에서 활용과 관련해서, 이 테스트 킷의 저작권이나 가격 등에 대한 논란이 있었습니다. 어쨌든 GCJ/Classpath나 Kaffe가 정식으로 certified되지 않는 한 엄밀하게 이들 제품은 '자바' 구현이 아닙니다).

그럼에도 creativeidler 님이 말씀하신 자바와 리눅스 진영이 친해지지 못한 아쉬움은 저도 공감하는 바입니다. 사실 최근 2-3년 사이 서버 시장에서 리눅스의 선전은 갑자기 PHP+MySQL 사이트가 늘어나서가 아니라 거의 J2EE의 성장에 힘입은 바가 크다는 건 명확한 사실이니까요...

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

지리즈의 이미지

자바도 모노도 리눅스에서 성공할려면,
가장 큰 산 펄과 파이썬, 그리고 php를 넘어야 할 것 같습니다.

지극히 개인적인 생각에서 자바,모노를 바라볼때,
이들 파이썬,php 특히 perl에 비하면 도톨이 키재기라는 생각이 듭니다.

There is no spoon. Neo from the Matrix 1999.

익명 사용자의 이미지

쓰레드를 쭉 읽어보니까, 약간 fender 님 말씀에 더 공감이 갑니다.

저도 웹 개발이랑은 하등 무관한 사람입니다만, fender 님이 갑자기 브라우저 이야기를 꺼낸 이유는 이해가 갑니다. 할로윈 문서에서도 들어났듯이 MS의 기본전략은 이미 있는 표준을 준수하면서 자신만의 새로운 기능을 더 추가해 그것을 많은 사람들이 사용하게 해, 결국 MS의 플랫폼에 의존하게 만드는 것입니다.

대표적으로 IE가 브라우저 시장을 장악한 것도 fender 님 말씀대로 그 전략 그대로 였습니다. 닷넷의 경우도 모든 부분(WinForm)을 포함한 것들이 전부 공개 표준으로 제출되어서 새로운 구현체로 인정 받을 수 있다면, 방준영 님 말씀에 전 크게 공감할 수 있을 것 같습니다.

그러나 문제는 그렇지가 않다는 점입니다. WinAPI 가 POSIX 같은 표준이라면 얼마나 좋겠습니까? 윈도우즈에서 POSIX 프로그램은 그런대로 컴파일 해서 돌릴 수 있지만, 반대로 WinAPI 를 POSIX 기반으로 옮겨 오기에는, 너무나도 많이 힘이듭니다. 공개 문서를 참조하고 역엔지니어링을 열심히 해서 알아내야만 그 API 를 구현할 수 있고, 이런 것들이 새로운 윈도우즈 플랫폼 구현체를 만드는데 너무나도 큰 걸림돌입니다.

닷넷의 WinFORM 등도 마찬가지입니다. 비공개적인 부분을 완벽하게 그것도 빠른 시간내에 구현해 낼 수 있다면, 아마 윈도우즈 사용자들 중 많은 사람들이 리눅스를 포함한 유닉스 진영으로 옮겨 올 것입니다. 만약 그것이 가능하다면 정말로 좋은 전략이 되겠지요. 가능만 하다면 시장에 엄청난 충격을 주는 것도 시간 문제일 것입니다.

문제는 불가능하다는 점입니다. 구현체를 만들어 봤자, 시간도 오래걸리고 불완전하고 저작권도 맘에 걸리고 그렇게 됩니다. 만약 모노가 Gtk# 등 공개적인 표준을 튼튼히 하면서 새로운 공개표준을 만들어, 닷넷의 또 다른 대안으로 성장한다면 정말로 괜찮겠지만, 기본 방향이 완벽한 닷넷 호환 플랫폼을 만들겠다라면, 그 목표는 좋을 지언정 결과적으로 그렇게 성공할 수 있을 것이라고 생각지 않습니다.

방준영님께서 지적하셨듯이 WinAPI 나 닷넷 등등 윈도우즈 것들이 오픈소스 진영에 비해 훨씬 풍부하고 좋은 기반이라는 점에 저도 어느 정도 공감하고, AMD가 인텔과 경쟁할 수 있는 이유가 하위 호환성 때문이라는 점도 공감이 가고, 90
% 이상을 차지하고 있는 "사실상 표준" 데스크탑 윈도우즈의 구현의 하위 호환성을 제공하는 것이 성공적인 전략이라는 것도 잘 알겠습니다만, 윈도우즈의 그 독자적인 수 많은 것들을 빠른 시일 내에 오픈 소스로 재 구현 할 수 있다는 점에서는 저는 기술적으로 불가능하다고 생각하고 있습니다.

결국 모노의 성공은 결코 완벽한 닷넷 컴포턴트의 재구현이라고 생각지 않습니다. 저는 아무래도 fender 님 의견에 공감이 많이 갑니다. GTK# 같이 완전히 공개적인 표준으로 윈도우즈와 리눅스에서 동시에 돌아가고, 효율적인 개발 플랫폼을 제공하는 것이 오히려 mono의 성공이라고 생각합니다.

creativeidler의 이미지

Quote:
그런데 freshmeat.net 등등에 등록된 수많은 오픈 소스 자바 프로젝트들이 썬 자바가 아닌 카페나 GCJ에서 돌아가느냐? 하면 그렇지가 않습니다.

이게 이유라는 건 이해하기 힘듭니다. 그건 전적으로 GCJ의 문제입니다. 썬의 JVM에서 돌아가는 프로그램이 다른 공인된 JVM에서 안 돌아가는 경우는 극히 드뭅니다. GCJ만 안 돌아갈 뿐이고 그 원인은 전적으로 GCJ에서 표준을 지키지 못했기 때문입니다.

HTML 표준 논쟁에 비추어서 생각해보십시오. 디자이너가 파이어폭스로 보면서 HTML 표준을 정확히 지켜서 코딩했습니다. 그런데 IE에서 보니까 제대로 안 나옵니다. 그럼 누구 잘못입니까? 물론 디자이너가 IE까지 고려해주면 좋긴 하겠죠. 하지만 잘잘못을 따진다면 잘못은 전적으로 표준을 준수하지 못한 IE에 있는 거 아니겠습니까.

자바도 마찬가지입니다. J2SE 스펙을 정확하게 지킨 구현체라면 안 돌아갈 리가 없습니다. 그런데 이걸 두고 개발자들이 테스트를 제대로 안했다고 말하는 것은 문제가 있죠.

그리고 자유를 이야기한다면 feanor님의 사고 방식이야말로 자유롭지 못한 사고방식인 것 같습니다. 오픈소스 진영에서는 반드시 모든 것이 오픈소스로 되어 있어야만 좋아하고 나머지는 전부 배척해야하나요? 오픈 소스는 오픈 마인드와는 거리가 많은 건가보죠?

그리고, 한 가지 정정할 말이 있습니다. 앞서, 오픈 소스 진영에서 자바를 싫어하고 평가절하한다고 표현한 적이 있는데, 이 표현을 잘못된 표현인 것 같습니다. GNU/리눅스 진영에서만 자바를 싫어하고 평가절하합니다. 사실 그 외에는 자바를 싫어하는 오픈 소스 그룹은 거의 없습니다. 오히려 자바 중심의 오픈소스 커뮤니티가 점점 더 늘어나고 있죠. 지금처럼 리눅스의 위상을 높여준 일등공신 Apache Group의 Jakarta Project만 봐도 되지 않겠습니까.

익명 사용자의 이미지

방준영 wrote:
리눅스 조차도 유닉스라는 비표준 기술을 베꼈죠. 그런데 정작 고소는 MS가 모노에게 한 것이 아니라 유닉스가 리눅스한테였지 않습니까. fender님 말씀이라면 아예 리눅스도 쓰지 말았어야 했을 듯 합니다.

리눅스는 정확하게 말해서 POSIX 라는 유닉스 표준을 구현하면서 시작했습니다. 리누스 자신도 유닉스 API 가 POSIX 표준과 같이 간결하지 않았다면 시작도 안했을 것이라고 말하고 있습니다. (Just For Fun에서..) POSIX 는 윈도 표준과는 다르게 그 당시 무료는 아니었지만, 구현을 얼마든지 허용하는 공개 표준이었습니다. 이 공개 표준을 리눅스가 따르므로써, 수 많은 프로그램들이 손쉽게 포팅 될 수 있었고, 이런 부분이 리눅스가 성공할 수 있는 요소로 작용했습니다.

방준영 wrote:
그리고 MS가 API 제정을 좌지우지하기 때문에 위험하다고도 하는데, 사실 유닉스 세계에서는 그보다 더 황당한 일이 계속 일어났습니다. API가 갑자기 망하거나 개발이 중단되어 버리는 거죠. Gtk와 Qt 이전에 있던 온갖 종류의 툴킷들 지금 다 어디로 갔나요.

적어도 MS의 것을 따른다면 최소한 앞으로 10년간은 마음놓고 개발할 수 있습니다.

툴킷이 없어지는 위험과 MS의 위험은 완전히 다른 종류의 것입니다. 앞에 글에서도 밝혔지만, MS가 자지우지하는 API를 완벽하게 따라잡는게 진실로 가능하다고 생각하십니까? 스펙조차 제대로 안나와 있는 API 들을 말입니다. 역엔지니어링을 통해서 알아내는 것도 이제 불법으로 인정 받을 수 있습니다. 그 밖에 WinAPI 라는 API 자체도 법적으로 하나의 저작권으로 인정받을 수 있을 지도 모릅니다. 그걸 재구현 하는 것조차 법적으로 딴지를 걸 수 있습니다. 법적으로 가능하다손 치더라도 그렇게 베일에 가려진 것들을 완벽히 재구현하려면 엄청난 맨파워가 필요합니다. 그리고 개발했다손 치더라도 그 사이에 MS의 API는 더 멀리 나가 있을 것이고 이미 많은 윈도우즈 사용자들이 널리 사용하고 있을 것입니다. fender 님 말씀은 바로 이런 점들이 위험하다는 것이 아니었나 싶습니다.

방준영 wrote:
Gtk/Qt의 애플리케이션이 수는 많을지 몰라도 쓸만한 것은 거의 없다고 할 수 있을 정도로 적습니다. 위에서 말씀드린 이유대로 기업에서는 Gtk/Qt 플랫폼을 거의 완전히 무시하고 있는 상황이구요. 쓰는 사람도 별로 없는데 언제 망할지도 모르겠고 기능은 불충분하고 개발 환경은 열악하고... 결국 모노의 대안으로 Gtk/Qt를 생각한다면 현상황에서 달라질 건 없습니다.

쓰는 사람이 "윈도우즈"에 비하면 엄청나게 적은 것은 사실이지만, 그렇다고 무시할 정도로 적은것도 아닙니다. 쓸만한 것은 거의 없다고 할 수 있을 정도로 적지 않습니다 :) 개발 환경은 점점 좋아지고 있고, 좋은 IDE 도 속속 나오고 있습니다. 과연 윈도우즈를 이길 수 있는 데스크탑 환경이 될 수 있을 지는 의문이지만, 그렇게 되지 않아도 상관 없습니다. 그리고 현 상황 조차 그렇게 나쁘다고 생각하지 않습니다. 최소한 윈도우즈가 없어도 컴퓨팅 할 수 있는 기반 만큼은 있으니까요. 그리고 충분히 윈도우즈가 부담스러운 환경에서는 리눅스 데스크탑은 시도할만하고 실제로 개발 도상국이나 유럽 국가에서는 그런 경우도 있습니다. 그것만으로도 하나의 조그만 시장은 만들었다고 생각합니다. 그 이상의 성공을 위한 전략은 많겠지만, 준영님은 방법은 멋지나 불가능하거나 정말로 힘든 방법인 것 같습니다.

feanor의 이미지

creativeidler wrote:
이게 이유라는 건 이해하기 힘듭니다. 그건 전적으로 GCJ의 문제입니다. 썬의 JVM에서 돌아가는 프로그램이 다른 공인된 JVM에서 안 돌아가는 경우는 극히 드뭅니다. GCJ만 안 돌아갈 뿐이고 그 원인은 전적으로 GCJ에서 표준을 지키지 못했기 때문입니다.

HTML 표준 논쟁에 비추어서 생각해보십시오. 디자이너가 파이어폭스로 보면서 HTML 표준을 정확히 지켜서 코딩했습니다. 그런데 IE에서 보니까 제대로 안 나옵니다. 그럼 누구 잘못입니까? 물론 디자이너가 IE까지 고려해주면 좋긴 하겠죠. 하지만 잘잘못을 따진다면 잘못은 전적으로 표준을 준수하지 못한 IE에 있는 거 아니겠습니까.

자바도 마찬가지입니다. J2SE 스펙을 정확하게 지킨 구현체라면 안 돌아갈 리가 없습니다. 그런데 이걸 두고 개발자들이 테스트를 제대로 안했다고 말하는 것은 문제가 있죠.

정말로 J2SE 스펙대로 짜면 안 돌아갈리가 없다고 생각하시나요? 그렇지 않다는 것을 알고 계시리라 생각합니다만... JVM이나 JLS는 두 사람이 문서만 보고 짜도 호환성 있는 물건이 나올만큼 잘 규정된 표준이라고 봅니다만, Javadoc이 HTML이나 (더 나아가) HTTP 정도의 표준이라고 생각하신다면 이건 곤란합니다. (앞에서 JBoss와 Kaffe의 예를 들었는데 읽어 보셨는지? 다른 예도 들어드릴 수 있습니다.)

그리고, 표준인가 아닌가와는 별개로 참조 구현(Reference implementation)이 자유로운가 그렇지 않은가는 상당히 중요한 문제입니다. 현재 "자바 플랫폼"은 GNU (나아가서 오픈 소스) 진영에서 볼 때 자유로운 플랫폼이 아닙니다.

제가 플래시의 예를 들었습니다. 플래시의 포맷이 공개되어 있으니, 오픈 소스 플래시 플레이어를 못 만들고 있는 것은 오픈 소스 진영이 바보인 것이고, 따라서 플래시를 적극 이용하는 오픈 소스 프로그램을 많이 많이 만들어야 한다고 생각하시나요?

--feanor

feanor의 이미지

표준과 자유로운 참조 구현의 중요성에 대해 예를 들어서 설명하고자 합니다. 앞에서 말한 "니가 틀렸다고 까댈 수 있는 자유"와도 일맥상통합니다.

http://httpd.apache.org/info/aol-http.html

1996년 HTTP 1.1 표준이 막 발표되었을 때, 아파치에서 보내는 정상적인 HTTP 1.1 응답을 AOL 프록시에서 차단한 일이 있습니다. 아파치에서는 자신들이 표준에 맞는 올바른 행동을 하고 있다고 선언하고는, AOL이 프록시 구현을 바꾸어야 한다고 주장했습니다. 자세한 내용은 링크를 보시기 바랍니다.

당시 아파치의 웹 서버 점유율은 약 30%였습니다. 이처럼 "개무시되지 않는" 자유로운 참조 구현이 있었기 때문에 HTTP가 현재와 같이 모두가 지키는 (지키려고 하는) 제대로 된 표준으로 자리잡을 수 있었다고 생각합니다.

--feanor

creativeidler의 이미지

feanor님이 무슨 말씀을 하시려는지 잘 모르겠습니다. 뭔가 반례들과 반문들을 던져놓으면 제가 알아서 착착 이해를 하길 바라시는 것 같은데 좀더 명확하게 자신의 주장을 서술해주셨으면 좋겠군요.

그나마 열심히 이해해본 바로는-_- javadoc이 HTML 정도의 표준이냐고 묻는 걸로봐서 HTML보다 훨씬 정확하지 않은 표준이기 때문에 javadoc API 구현해봐야 제대로 돌아간다는 것을 보증할 수 없다. GCJ는 javadoc을 다 구현했음에도 불구하고 잘 안도는 app가 있다..뭐 이런 얘기가 아닐까 싶은데-_-

전 javadoc API만을 말한 것이 아니라 TCK를 말한 겁니다. GCJ가 TCK를 통과했나요? 통과하려는 의지조차 없는 걸로 알고 있습니다. kaffe 역시 마찬가지로 알고 있구요. 그러니 J2SE에서 도는 프로그램이 GCJ 에서 돌아간다는 보장을 못하는 거죠.

플래시의 예는 왜 들었는지 잘 모르겠습니다. 전 자바가 좋으니까 자바를 써야한다! 가 아니라 자바를 쓰면 이득이니까 자바에 대한 편견 때문에 리눅스가 발전할 기회를 놓치지 말자는 겁니다. 플래시도 마찬가지죠. 이미 오픈소스 진영에서 플래시와 관련한 프로덕트를 만들려는 시도를 많이 하고 있는 걸로 알고 있습니다.

두번째 쓰신 글 역시 이해가 잘 안 갑니다. 예전부터 feanor님 글 보면서 느낀 건 뭔가 말은 많이 하는데 핵심이 되는 주장을 직접 서술하지 않아서 뭔 소린지 잘 안 잡힌다는 건데 이번도 좀 그러네요. 이번에 드신 예는 제 주장을 뒷받침하는 것 같아보입니다만?

서정민의 이미지

모노의 기술적인 미래를 보려고 왔는데, 결국 다른 이념으로 논쟁을 하는 수많은 오픈소스 진영의 정치적 싸움 밖에 보지 못하고 가는군요.

제가 오픈소스에 관심을 가지고, 현재도 관심을 가지는 이유는 개발자에게 주는 오픈소스의 즐거움이었습니다. 이러한 정치적인 싸움은 물론 오픈소스의 발전을 이룩하자는 의미도 있겠지만, 오픈소스 내의 자신의 영역을 확고히 하고자하는 욕심쟁이들의 땅따먹기 싸움으로 밖에 보이지 않는군요.

모노가 닷넷을 오픈소스화해보자는 순수한 재미에서 시작되었다면, 그 재미가 계속 지속되는한 모노는 아직 발전할 앞날은 창창하다고 할 수 있겠습니다. 하지만, 이러한 정치적 싸움에 휘말려 모노는 '미래가 없다'와 같은 인식을 오픈소스 개발자들에게 심어주면서 참여개발자들이 줄어든다면 여느 수많은 오픈소스 프로젝트처럼 자연스럽게 조용히 역사로 묻혀버리게 되겠죠.

오픈소스가 주는 장점을 더 키우기 위한 오픈소스 진영의 정치적 행동은 어디로 이어질지 궁금하며, 언젠가는 이러한 욕심으로 인하여 이 분야도 다른 더 새로운 개념의 운동에 의해서 탄압되는 날이 오기를 기원하면서 답변글을 마무리합니다.

hey의 이미지

저도 잘 아는 건 아니지만..

모노가 재미를 위해 시작되었고 열심히 재밌게 만든다면, 오픈소스 진영에서 그건 정말 아무 문제도 아니고, 오히려 장려되는 활동일 겁니다. 그러나 지미안, 그리고 미겔은 그놈 진영에 어느 정도 이상의 발언권이 있고 꼭 그렇지 않다 하더라도 그를 추종하는 많은 개발자들이 모노를 잠정적인 그놈의 플랫폼으로 여길 가능성이 있습니다. 이쯤되면 지미안은 우리가 재미를 위해 만드는데 무슨 문제냐!? 하고 말할 수 없는 책임을 가져야만 합니다. 그놈 진영이 좌초하지 않게 해야 할 책임이지요.

그래서 이 위의 모든 토론이 시작되게 된 것입니다.

아, 그리고 쓰레드를 '원하는 어떤 주제를 보기 위해' 읽기 시작했을 때, 그 쓰레드가 내가 원하는 내용의 쓰레드가 아니라는 것은 그 쓰레드나 그 쓰레드를 끌어간 여러 작성자들의 문제는 아니지 않을까요? 그냥 내가 생각한 쓰레드가 아니었다는 것 뿐이죠.


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


익명 사용자의 이미지

.NET은 ECMA표준으로 공개된 규격 위에서 MS만의 독자적인 ADO.NET, ASP.NET, WinForm등으로 이루어집니다.

구현이 웹이냐, GUI이냐에 따라서 ASP.NET이냐, WinForm이냐로 갈리고, 두 가지 환경에서 모두 DB를 사용할려면 ADO.NET을 사용합니다.
이 모든 것이 ECMA표준 규격 위에서 돌아가구요.

저는 WinForm을 주로 개발하고, ASP.NET은 그냥 공부만 하고, 실험만 해 보았습니다.

우선 Mono는 ADO.NET과 ASP.NET만을 구현하고, WinForm은 구현하지 않았습니다.
제가 보기에는 그 이유는 WinForm은 다른 부분과 달리 윈도우 메세지등 윈도우 구조에 의존하는 부분이 많아서 리눅스 상에서 개발하기 힘든 것이 그 이유인 것 같습니다.

그런 ASP.NET이 얼마나 효용성이 있는가?
저는 JAVA와 큰 차이가 없다고 생각합니다. 오히려, 큰 규모의 프로젝트 레퍼런스나 개발자 커뮤니티 규모면에서는 못하다고 생각합니다.
Visual Studio에서 GUI프로그램 짜듯이 웹페이지를 설계할 수 있다는 큰 장점이 있지만, 웹의 특성상 버튼 클릭을 제외한 대부분의 이벤트는 Javascript로 HTML노가다를 해서 구현해야 합니다.
겉만 GUI처럼 설계하지 실제 이벤트 코팅은 HTML노가다라는 말씀되겠습니다.
(웹상에서 어플리케이션을 구현한다는 가정하에서 말입니다.)
거기다가 설사 서버가 이벤트를 받아서 처리할 수 있다고 해서 submit해서 응답을 받는 시간이 있기 때문에 GUI와 같은 프로그램을 웹상에서 구현한다는 것은 힘듭니다.
기업용 프로그램을 짤 때는 다수의 사용자가 적은 입력을 하는 경우도 있겠지만, 전문입력요원이 아주 빠른 속도로 대량의 데이터를 입력하는 경우도 많다는 것을 고려하면 별 매력없는 선택입니다.
(제가 다니는 회사 모기업이 ASP.NET으로 ERP구축한다던데, 과연 성공할 수 있을까 의문입니다. 지금 당초 예상한 개발기한 한참 지나서 버벅이는 데 실패할 것 같습니다.)

거기다가 Mono의 ASP.NET구현은 더 심각한 문제가 있습니다.
Apache서버에 들어가는 ASP.NET모듈에서 메모리 누수현상이 있어서 로드가 조금 걸리면 서버가 죽습니다.
제대로 ASP.NET를 서비스 할려면 꼼짝없이 MS윈도우 써야 됩니다.

제가 주로 사용하는 WinForm의 경우는 이야기가 다릅니다.
delegate라는 이벤트 형식을 이용하는 데, 이것으로 인해서 폼을 하나의 객체처럼 다루고, 상속할 때 부모폼에서 설정한 컨트롤들의 모든 이벤트 코딩들이 자식 폼에서도 작동하는 놀라운 모습을 보입니다.
공통된 부분을 가지는 부모폼 몇 개 만들고, 조금씩 다른 부분만 상속해서 폼을 만들어가면 엄청난 생산성 향상을 체감할 수 있습니다.
(제가 그 덕을 톡톡히 보고 있습니다.)
저는 클래스를 사용해서 객체지향프로그래밍은 잘못하지만, 폼(GUI형 클래스쯤 될려나요?)을 상속받고, 다형성을 사용하는 것은 너무나 쉽습니다.
속도도 쓸만하고, 중간 중간에 JIT컴파일 되느라 멈칫거리는 게 싫으면, ngen이라는 .NET SDK에 딸려나오는 프로그램으로 기계코드로 컴파일 하면 멈칫거리는 것도 없어지고, 초기에 컴파일하느라 뜸들이는 것도 사라집니다.

문제는 Mono에는 WinForm이 구현이 안 되어(덜 되어) 있다는 겁니다.

지금 당장은 Mono가 큰 효용성은 없다고 보실 수도 있습니다.
그러나, C#으로 처음부터 모든 WinForm컨트롤을 구현하는 프로젝트가 상당한 속도로 진행 중입니다.
C#으로 구현된다는 말은 메모리 누수는 걱정할 필요가 없다는 이야기이고, 상당한 안정성이 예상됩니다.
C#으로 구현하면 좀 느리겠지만, 요즘 컴퓨터들이 좀 빠릅니까?
잘 될 거라고 생각합니다.
WinForm구현이 되면, 엄청난 일이 생기는 겁니다.
윈도우와 리눅스를 동시에 지원하는 프로그램을 짜는 것이 아주 용이해지므로, 기업에서 .NET으로 전산프로그램을 구현하면 윈98, 윈Me를 사용하던 컴퓨터들 여차하면 리눅스로 바꾸는 것이 가능해 집니다.
.NET으로 구현하는 GUI의 생산성이 원체 높으므로(제 경험상) 상당히 매력적인 선택이 될 수 있습니다.

진짜 문제는 롱혼(윈XP 다음의 윈도우)가 나온 후입니다.
.NET에서 롱혼의 새로운 기능을 이용하는 API가 많이 나올텐데, 이것은 OS에서부터 나온 기능을 기반으로 하기 때문에 유사기능이 리눅스에 없을 경우 Mono에서 구현하기가 아주 힘들어집니다.

지금 새로 나온 롱혼의 새로운 기능들은 하나하나로 따지면, 별 다른 것이 없지만 합쳐졌을 경우, 웹페이지에서 바로 GUI프로그램을 받아서 실행시킬 수 잇는, (Java에서는 이런 것을 애플릿이라고 부르나요?) 웹과 GUI의 장점을 합친 프로그래밍이 가능해진다고 Miguel이 말했습니다. 아니 저는 그렇게 알아 들었습니다만 틀릴 수 있겟죠? 영어 해석이라..
이런 중요한 장점을 Mono가 구현하지 못하면 Mono의 가치는 약간 덜해지겠지요.

그러나, 아주 생산성 높은 GUI개발환경에서 개발한 프로그램을 별다른 수정없이 윈도우와 리눅스에서 사용할 수 있게 된다면 그것만으로도 Mono의 가치는 여전할 것입니다.
또, XP도 나온 지 한참되었는 데 50%정도의 점유율만 가지고 있는 것을 생각하면, Mono가 구현하는 데 가질 시간은 충분하리라 봅니다.

MS가 계속해서 API를 변경시키고, Mono는 끝없이 쫓아가기만 한다는 말은 한편으로는 맞고 한편으로는 맞지 않습니다.
.NET 최신버전의 기능은 한없이 쫓아가야 합니다.
그러나, .NET은 여러가지 버전이 동시에 설치 및 실행이 가능하게 되어있습니다.
그러므로, 하나의 버전은 발표가 되는 동시에 고정이 되고, 그것을 목표로 쫓아가서 구현하게 되면 결국은 다 구현할 수 있습니다.
새로운 버전이 나와도, 이전 버전과 함께 설치하면 되니까 이전버전을 사용하도록 프로그램 하면 됩니다.
그리고, Mono는 이전버전에 대한 구현을 마친 후, 새로운 기능을 추가해 나가면 됩니다.

새로운 버전이 너무 빨리 계속해서 나오면 아주 낮은 버전만을 사용할 수 밖에 없지 않느냐고 생각하실지 모르겠는 데, Mono의 구현속도는 .NET의 새로운 버전이 나오는 속도와 비슷합니다.
거기에다가 각 Visual Studio버전은 해당 ..NET버전의 개발만 가능합니다.

Visual Studio .NET 처음 버전은 .NET 1.0의 개발만 가능했습니다.
Visual Studio .NET 2003버전은 .NET 1.1의 개발만 됩니다.
Visual Studio .NET 2005버전은 .NET 2.0의 개발만 될 것입니다.
Visual Studio안에는 해당 .NET SDK가 (당연히) 들어있습니다.
이것이 의미하는 바는 거꾸로 Mono가 지원하는(목표로 하는) .NET버전에 대응하는 Visual Studio가 있으면 해당 .NET버전도 가지고 있으므로 MS가 웹사이트에서 해당 .NET버전을 지우거나 찾기 어렵도록 꼭꼭 숨겨놓아도, 이전버전의 .NET은 계속해서 사용할 수 있다는 말이 됩니다.

저는 표준의 정의에도 관심없고, Java가 오픈소스가 아니니, Mono는 오픈소스이니 하는 것에도 별 관심 없습니다.
가장 적은 비용으로 가장 큰 효과를 볼 수 있는 것이 좋습니다.

저같은 경우 웹프로그래밍은 잼병이라서 웹 쪽은 별 관심없고, GUI의 경우 WinForm이 편하므로 Java의 Swing, SWF에는 관심없습니다.
그리고, 리눅스가 높은 사양을 요구하지 않으므로 오래된 컴퓨터에서 돌릴 수 있고, 라이센스 비용도 낮거나 없으므로, 클라이언트로 리눅스 사용하기를 희망합니다.

윈도우용으로 짠 프로그램을 리눅스에서 별다른 소스 수정없이 돌릴 수 있다면 아주 좋을 것입니다. 그런면에서 저는 Mono를 아주 높이 평가하고 있으며, 지금 WinForm을 구현하는 프로젝트의 진행상황을 자주 체크하고 있습니다.
저는 주로 ComboBox, TextBox, DataGrid를 사용하므로, DataGrid만 구현되면 실제로 옮겨가는것을 고려해 볼 수 있지 않을까 생각하고 있습니다.
전산프로그램으로 생산현황이나 조회하고, 엑셀로 자기 자료 정리하는 관리직원들 한테는 리눅스에 전산프로그램깔고, OpenOffice 던져주면 되지 않을까 생각 합니다.

익명 사용자의 이미지

Qt는 크로스 플랫홈(Windows, Mac, Unix계열)을 지원함니다.
C++기반으로 만들어졌고 signal과 slot이라는 독특한 개념으로
메시지방식과는 다른 방법을 사용합니다.
GUI에 관한 모든 것이 지원되는 것 같습니다.
제가 써보니 괜찮은 것 같습니다.
Windows에서 작성한 코드를 Linux에서 컴파일 환경만 바꾸어주면
바로 사용할 수 가 있더군요..

자세한 것은
http://www.trolltech.com에서 확인하세요

sDH8988L의 이미지

손님 wrote:
...
C#으로 구현하면 좀 느리겠지만, 요즘 컴퓨터들이 좀 빠릅니까?
잘 될 거라고 생각합니다.
WinForm구현이 되면, 엄청난 일이 생기는 겁니다.
윈도우와 리눅스를 동시에 지원하는 프로그램을 짜는 것이 아주 용이해지므로, 기업에서 .NET으로 전산프로그램을 구현하면 윈98, 윈Me를 사용하던 컴퓨터들 여차하면 리눅스로 바꾸는 것이 가능해 집니다.
.NET으로 구현하는 GUI의 생산성이 원체 높으므로(제 경험상) 상당히 매력적인 선택이 될 수 있습니다.
...
...
...

윈도우용으로 짠 프로그램을 리눅스에서 별다른 소스 수정없이 돌릴 수 있다면 아주 좋을 것입니다. 그런면에서 저는 Mono를 아주 높이 평가하고 있으며, 지금 WinForm을 구현하는 프로젝트의 진행상황을 자주 체크하고 있습니다.
저는 주로 ComboBox, TextBox, DataGrid를 사용하므로, DataGrid만 구현되면 실제로 옮겨가는것을 고려해 볼 수 있지 않을까 생각하고 있습니다.
전산프로그램으로 생산현황이나 조회하고, 엑셀로 자기 자료 정리하는 관리직원들 한테는 리눅스에 전산프로그램깔고, OpenOffice 던져주면 되지 않을까 생각 합니다.

Java와 뭐가 다르죠?

위 글들에서 .NET을 빼고 Java라는 말을 넣어도 거의 성립되는 글 같은 데요.

CrossPlatform으로 인해서 OS의 장벽이 무너진다는 얘기는 Java가 나올 시점부터 있던 이야기 입니다. .Net이라고 해서 Java보다 나은 뭔가를 보이기는 힘들 거 같은데요.

그리고 요즘 Linux도 예전에 비해서 상당히 고성능의 사양을 요구합니다. 그리고 Linux를 저사양에서 돌 수 있도록 만든다고 하더라도 .Net 자체가 고사양을 요구합니다. 그러면 당연히 고사양 컴퓨터를 써야 하죠. Java에서 문제점으로 지적되는 것들은 대부분 .Net에서도 문제점으로 지적될 수 있습니다. 거의 비슷한 구조를 채택하고 있기 때문일 겁니다.

위 글은 아마 .Net이 나오고 얼마 안된 시점에서 나왔을 법한 글이네요.

익명 사용자의 이미지

손님 wrote:

우선 Mono는 ADO.NET과 ASP.NET만을 구현하고, WinForm은 구현하지 않았습니다.
제가 보기에는 그 이유는 WinForm은 다른 부분과 달리 윈도우 메세지등 윈도우 구조에 의존하는 부분이 많아서 리눅스 상에서 개발하기 힘든 것이 그 이유인 것 같습니다.

mono 에서 winform 부분은 gtk+ wrapper 입니다. 즉 gtk+ 위젯의 바인딩입니다. winform 쪽의 작업이 늦어지는 이유는 제 생각에는 각 컨트롤들의 프로퍼티등이 상이한 부분이 가장 큰 부분이 아닐까 생각됩니다. 버튼이라도 windows의 버튼의 특성과 gtk+ 버튼 위젯의 특성은 다를테니까요. 어쩌면 winform 부분은 소스호환이 완벽히 안될지도 모릅니다.

손님 wrote:

그런 ASP.NET이 얼마나 효용성이 있는가?
저는 JAVA와 큰 차이가 없다고 생각합니다. 오히려, 큰 규모의 프로젝트 레퍼런스나 개발자 커뮤니티 규모면에서는 못하다고 생각합니다.
Visual Studio에서 GUI프로그램 짜듯이 웹페이지를 설계할 수 있다는 큰 장점이 있지만, 웹의 특성상 버튼 클릭을 제외한 대부분의 이벤트는 Javascript로 HTML노가다를 해서 구현해야 합니다.
겉만 GUI처럼 설계하지 실제 이벤트 코팅은 HTML노가다라는 말씀되겠습니다.
(웹상에서 어플리케이션을 구현한다는 가정하에서 말입니다.)

아시다시피 asp.net 은 컴포넌트 기반의 개발을 합니다. webform control 은 html 의 단순 태그가 아닙니다. 예로 버튼 웹컨트롤은 위의 html 노가다를 줄이기 위해 하나의 컴포넌트로 만들어 둔것입니다. 물론 webform control들을 사용하지 않고 개발 하신다면 "html 노가다" 를 하셔야 겠지만 webform 컨트롤을 사용하면 상당부분 그런 수고를 덜수 있습니다. 님께서 말하시는 "html/javascript 노가다" 부분을 컴포넌트로 만들어 사용하시면 그런 수고를 덜수 있겠습니다.

손님 wrote:

거기다가 설사 서버가 이벤트를 받아서 처리할 수 있다고 해서 submit해서 응답을 받는 시간이 있기 때문에 GUI와 같은 프로그램을 웹상에서 구현한다는 것은 힘듭니다.
기업용 프로그램을 짤 때는 다수의 사용자가 적은 입력을 하는 경우도 있겠지만, 전문입력요원이 아주 빠른 속도로 대량의 데이터를 입력하는 경우도 많다는 것을 고려하면 별 매력없는 선택입니다.
(제가 다니는 회사 모기업이 ASP.NET으로 ERP구축한다던데, 과연 성공할 수 있을까 의문입니다. 지금 당초 예상한 개발기한 한참 지나서 버벅이는 데 실패할 것 같습니다.)

이미 상당수 si 프로젝트가 웹기반으로 되어 있고 현재도 많은 수의 프로젝트가 웹기반으로 하고 있습니다. 물론 웹기반이 전용 클라이언트만큼 퀄리티내기가 수월치 않겠지만 관리(서버만 관리하면 되므로...)와 배포가 수월하다는 장점이 있습니다. 클라이언트 관리 해보신 분들은 아시겠지만 상당히 골치 아픕니다.^^
또한 퍼포먼스의 부분...대부분 si 프로젝트라면 인트라넷 환경일겁니다. 전문입력요원이 타이핑 하는 속도가 submit 하는 속도보다 빠른 경우는 드물것이란 제 개인적인 판단입니다. 이미 많은 수의 대규모 프로젝트가 웹기반으로 작성되어 서비스 되고 있습니다.

손님 wrote:

제가 주로 사용하는 WinForm의 경우는 이야기가 다릅니다.
delegate라는 이벤트 형식을 이용하는 데, 이것으로 인해서 폼을 하나의 객체처럼 다루고, 상속할 때 부모폼에서 설정한 컨트롤들의 모든 이벤트 코딩들이 자식 폼에서도 작동하는 놀라운 모습을 보입니다.

asp.net 과 winform 의 경우가 다른데...그 이유가 델리게이트? 좀...이유가 부적절한것 같습니다. asp.net에서도 델리게이트 사용가능합니다. 이 델리게이트라는 것이 별것이 아닙니다. c/c++ 의 함수 포인터 입니다.

손님 wrote:

지금 당장은 Mono가 큰 효용성은 없다고 보실 수도 있습니다.
그러나, C#으로 처음부터 모든 WinForm컨트롤을 구현하는 프로젝트가 상당한 속도로 진행 중입니다.
C#으로 구현된다는 말은 메모리 누수는 걱정할 필요가 없다는 이야기이고, 상당한 안정성이 예상됩니다.
C#으로 구현하면 좀 느리겠지만, 요즘 컴퓨터들이 좀 빠릅니까?
잘 될 거라고 생각합니다.
WinForm구현이 되면, 엄청난 일이 생기는 겁니다.
윈도우와 리눅스를 동시에 지원하는 프로그램을 짜는 것이 아주 용이해지므로, 기업에서 .NET으로 전산프로그램을 구현하면 윈98, 윈Me를 사용하던 컴퓨터들 여차하면 리눅스로 바꾸는 것이 가능해 집니다.
.NET으로 구현하는 GUI의 생산성이 원체 높으므로(제 경험상) 상당히 매력적인 선택이 될 수 있습니다.

mono와 닷넷은 별개로 봐야 합니다. 닷넷은 오로지 윈도우 플랫폼에 종속적입니다. 물론 소스와 IL 호환이 약간 가능할지 모르겠으나 만족할만한 수준은 어려울듯 합니다. 제 생각에 현재 윈도우와 리눅스를 지원하는 도구중 가장 만족할만한 것이 델파이/카일릭스 정도가 아닌듯 합니다.

손님 wrote:

거기에다가 각 Visual Studio버전은 해당 ..NET버전의 개발만 가능합니다.

Visual Studio .NET 처음 버전은 .NET 1.0의 개발만 가능했습니다.
Visual Studio .NET 2003버전은 .NET 1.1의 개발만 됩니다.
Visual Studio .NET 2005버전은 .NET 2.0의 개발만 될 것입니다.
Visual Studio안에는 해당 .NET SDK가 (당연히) 들어있습니다.
이것이 의미하는 바는 거꾸로 Mono가 지원하는(목표로 하는) .NET버전에 대응하는 Visual Studio가 있으면 해당 .NET버전도 가지고 있으므로 MS가 웹사이트에서 해당 .NET버전을 지우거나 찾기 어렵도록 꼭꼭 숨겨놓아도, 이전버전의 .NET은 계속해서 사용할 수 있다는 말이 됩니다.


솔직히 위의 말씀은 도무지 잘 이해가 안되서..제가 잘못 이해하고 작성할수도 있습니다.
너무 큰 착각을 하고 계신듯 하신데 .net 기반의 개발을 할때 비주얼 스튜디오가 있어야만 가능한 것이 아닙니다. .net 을 지원하는 개발툴도 비주얼 스튜디오만 있는 것도 아니며(아시다시피 .net은 언어에 독립적이죠. 이미 볼랜드에서는 c#빌더, delphi for .net 등이 있습니다.) 에디터 하나만으로도 개발 가능합니다. 비주얼 스튜디오가 특정 버전의 닷넷 프레임워크에 종속되어 있어서...라는 말은 맞지가 않습니다. 거기다가 가장 문제가 될수 있는 소지가 닷넷은 ms의 기술이라는 것입니다. 나중에(mono가 영향력이 있을쯤...) 어떤 딴지를 걸지 알수 없는 노릇입니다.
sangu의 이미지

Anonymous wrote:
손님 wrote:

우선 Mono는 ADO.NET과 ASP.NET만을 구현하고, WinForm은 구현하지 않았습니다.
제가 보기에는 그 이유는 WinForm은 다른 부분과 달리 윈도우 메세지등 윈도우 구조에 의존하는 부분이 많아서 리눅스 상에서 개발하기 힘든 것이 그 이유인 것 같습니다.

mono 에서 winform 부분은 gtk+ wrapper 입니다. 즉 gtk+ 위젯의 바인딩입니다. winform 쪽의 작업이 늦어지는 이유는 제 생각에는 각 컨트롤들의 프로퍼티등이 상이한 부분이 가장 큰 부분이 아닐까 생각됩니다. 버튼이라도 windows의 버튼의 특성과 gtk+ 버튼 위젯의 특성은 다를테니까요. 어쩌면 winform 부분은 소스호환이 완벽히 안될지도 모릅니다.

mono 1.0.x까지 WinForm은 GTK+하고 관련이 없고 리눅스일 경우 mono의 WinForm은 Wine을 이용해서 실행 되고 있습니다. Gtk#은 단순히 GTK+ 바이딩입니다.

hys545의 이미지

sangu wrote:
Anonymous wrote:
손님 wrote:

우선 Mono는 ADO.NET과 ASP.NET만을 구현하고, WinForm은 구현하지 않았습니다.
제가 보기에는 그 이유는 WinForm은 다른 부분과 달리 윈도우 메세지등 윈도우 구조에 의존하는 부분이 많아서 리눅스 상에서 개발하기 힘든 것이 그 이유인 것 같습니다.

mono 에서 winform 부분은 gtk+ wrapper 입니다. 즉 gtk+ 위젯의 바인딩입니다. winform 쪽의 작업이 늦어지는 이유는 제 생각에는 각 컨트롤들의 프로퍼티등이 상이한 부분이 가장 큰 부분이 아닐까 생각됩니다. 버튼이라도 windows의 버튼의 특성과 gtk+ 버튼 위젯의 특성은 다를테니까요. 어쩌면 winform 부분은 소스호환이 완벽히 안될지도 모릅니다.

mono 1.0.x까지 WinForm은 GTK+하고 관련이 없고 리눅스일 경우 mono의 WinForm은 Wine을 이용해서 실행 되고 있습니다. Gtk#은 단순히 GTK+ 바이딩입니다.

현제 winform은 swf#으로 전환중이라고 알고 있습니다.
소스 보면 winelib하고 swf하고 같이 winfirms밑에 있습니다.
그런데 이거 시간이 걸릴거 같습니다.

즐린

익명 사용자의 이미지

sDH8988L wrote:
손님 wrote:
...
C#으로 구현하면 좀 느리겠지만, 요즘 컴퓨터들이 좀 빠릅니까?
잘 될 거라고 생각합니다.
WinForm구현이 되면, 엄청난 일이 생기는 겁니다.
윈도우와 리눅스를 동시에 지원하는 프로그램을 짜는 것이 아주 용이해지므로, 기업에서 .NET으로 전산프로그램을 구현하면 윈98, 윈Me를 사용하던 컴퓨터들 여차하면 리눅스로 바꾸는 것이 가능해 집니다.
.NET으로 구현하는 GUI의 생산성이 원체 높으므로(제 경험상) 상당히 매력적인 선택이 될 수 있습니다.
...

Java와 뭐가 다르죠?

위 글들에서 .NET을 빼고 Java라는 말을 넣어도 거의 성립되는 글 같은 데요.

CrossPlatform으로 인해서 OS의 장벽이 무너진다는 얘기는 Java가 나올 시점부터 있던 이야기 입니다. .Net이라고 해서 Java보다 나은 뭔가를 보이기는 힘들 거 같은데요.

그리고 요즘 Linux도 예전에 비해서 상당히 고성능의 사양을 요구합니다. 그리고 Linux를 저사양에서 돌 수 있도록 만든다고 하더라도 .Net 자체가 고사양을 요구합니다. 그러면 당연히 고사양 컴퓨터를 써야 하죠. Java에서 문제점으로 지적되는 것들은 대부분 .Net에서도 문제점으로 지적될 수 있습니다. 거의 비슷한 구조를 채택하고 있기 때문일 겁니다.

위 글은 아마 .Net이 나오고 얼마 안된 시점에서 나왔을 법한 글이네요.

Java와 .Net의 차이점은 Web개발이 아닌 일반 GUI 클라이언트 개발에서 생산성 차이라고 생각합니다.
더 구체적으로 말하면, Eclipse나 NetBeans를 사용해서 GUI클라이언트를 개발하는 생산성과 Visual Studio를 사용해서 GUI클라이언트를 개발하는 것 간의 차이를 말합니다.
님 말씀대로 crossplatform이야 예전부터 Java가 제창해 왔던 것이죠.
.Net은 MS가 Java베낀 것이고요.

익명 사용자의 이미지

Anonymous wrote:
손님 wrote:

우선 Mono는 ADO.NET과 ASP.NET만을 구현하고, WinForm은 구현하지 않았습니다.
제가 보기에는 그 이유는 WinForm은 다른 부분과 달리 윈도우 메세지등 윈도우 구조에 의존하는 부분이 많아서 리눅스 상에서 개발하기 힘든 것이 그 이유인 것 같습니다.

mono 에서 winform 부분은 gtk+ wrapper 입니다. 즉 gtk+ 위젯의 바인딩입니다. winform 쪽의 작업이 늦어지는 이유는 제 생각에는 각 컨트롤들의 프로퍼티등이 상이한 부분이 가장 큰 부분이 아닐까 생각됩니다. 버튼이라도 windows의 버튼의 특성과 gtk+ 버튼 위젯의 특성은 다를테니까요. 어쩌면 winform 부분은 소스호환이 완벽히 안될지도 모릅니다.

mono에서 새로 개발하고 있는 winform은 gtk+ wrapper가 아니라 윈도우 메시지등 하부구조 에뮬레이션을 포함해서 완전히 새로 개발하는 것으로 알고 있습니다.
고로 저 개인적으로는 소스레벨에서는 호환성에 문제가 없을거라고 생각합니다.

Anonymous wrote:
손님 wrote:

그런 ASP.NET이 얼마나 효용성이 있는가?
저는 JAVA와 큰 차이가 없다고 생각합니다. 오히려, 큰 규모의 프로젝트 레퍼런스나 개발자 커뮤니티 규모면에서는 못하다고 생각합니다.
Visual Studio에서 GUI프로그램 짜듯이 웹페이지를 설계할 수 있다는 큰 장점이 있지만, 웹의 특성상 버튼 클릭을 제외한 대부분의 이벤트는 Javascript로 HTML노가다를 해서 구현해야 합니다.
겉만 GUI처럼 설계하지 실제 이벤트 코팅은 HTML노가다라는 말씀되겠습니다.
(웹상에서 어플리케이션을 구현한다는 가정하에서 말입니다.)

아시다시피 asp.net 은 컴포넌트 기반의 개발을 합니다. webform control 은 html 의 단순 태그가 아닙니다. 예로 버튼 웹컨트롤은 위의 html 노가다를 줄이기 위해 하나의 컴포넌트로 만들어 둔것입니다. 물론 webform control들을 사용하지 않고 개발 하신다면 "html 노가다" 를 하셔야 겠지만 webform 컨트롤을 사용하면 상당부분 그런 수고를 덜수 있습니다. 님께서 말하시는 "html/javascript 노가다" 부분을 컴포넌트로 만들어 사용하시면 그런 수고를 덜수 있겠습니다.

제 기억으로는 WebForm 컨트롤도 이벤트가 몇개 안 되고, 지원 안 되는 이벤트는 javascript로 처리해야되는 것은 마찬가지 인것으로 기억합니다.
저 개인적으로 입력편의를 위해서 focus를 받거나, 잃거나, 키보드 입력값을 검사하는 3가지 이벤트를 많이 사용합니다.
(입력값에 따라서 폼이 동적으로 변화하게 하는 데 많이 사용하죠.)
WebForm에서도 3가지 이벤트 중 하나도 지원해 주지 않더군요.
제 개인적인 결론은 'ASP.NET에서 입력편의성이 높은 폼을 만들려면 Javascript를 잘 알아야한다' 였습니다.
그리고, Javascript를 많이 이용하게 되면, .Net이 자랑하는 Presentation과 Coding을 분리한다는 것은 완전히 물건너간 것 되겠습니다.

Anonymous wrote:
손님 wrote:

거기다가 설사 서버가 이벤트를 받아서 처리할 수 있다고 해서 submit해서 응답을 받는 시간이 있기 때문에 GUI와 같은 프로그램을 웹상에서 구현한다는 것은 힘듭니다.
기업용 프로그램을 짤 때는 다수의 사용자가 적은 입력을 하는 경우도 있겠지만, 전문입력요원이 아주 빠른 속도로 대량의 데이터를 입력하는 경우도 많다는 것을 고려하면 별 매력없는 선택입니다.
(제가 다니는 회사 모기업이 ASP.NET으로 ERP구축한다던데, 과연 성공할 수 있을까 의문입니다. 지금 당초 예상한 개발기한 한참 지나서 버벅이는 데 실패할 것 같습니다.)

이미 상당수 si 프로젝트가 웹기반으로 되어 있고 현재도 많은 수의 프로젝트가 웹기반으로 하고 있습니다. 물론 웹기반이 전용 클라이언트만큼 퀄리티내기가 수월치 않겠지만 관리(서버만 관리하면 되므로...)와 배포가 수월하다는 장점이 있습니다. 클라이언트 관리 해보신 분들은 아시겠지만 상당히 골치 아픕니다.^^
또한 퍼포먼스의 부분...대부분 si 프로젝트라면 인트라넷 환경일겁니다. 전문입력요원이 타이핑 하는 속도가 submit 하는 속도보다 빠른 경우는 드물것이란 제 개인적인 판단입니다. 이미 많은 수의 대규모 프로젝트가 웹기반으로 작성되어 서비스 되고 있습니다.

님의 말씀 중 웹클라이언트가 배포가 수월하다는 부분은 십분 공감합니다.
그래서, 저도 입력량이 적은 다수의 사용자가 사용하는 폼(예 : 조회, 검색폼)은 웹환경의 장점이 크다고 생각합니다.

그러나, 제가 문제를 제기한 부분은 전문입력요원이 사용하는 입력량이 많은 폼입니다.
데이터 입력을 마친 후에 최종적으로 하는 submit이 타이핑속도보다 느리지는 않겠지만, 입력 중간 중간에 이벤트처리를 위해서 하는 submit의 경우는 타이핑 조금하는 사람에게는 엄청난 장애물입니다.
이벤트처리를 위해서 하는 submit을 없앨려면, Javascript노가다가 늘어나서 생산성이 떨어집니다.
제 개인적으로는 전문입력요원이 사용하는 데이터 입력용 폼을 웹에서 구현하는 것은 쉽게 할 수 있는 어렵고 비효율적으로 하는 대표적인 예라고 생각합니다.
그리고, 자기가 이루고자 하는 목적에 가장 효율적인 도구를 쓰는 것이 합리적이라고 생각합니다만, 웹이 과연 그런 용도로 개발되었는 지에 대한 의문이 들 정도입니다.
웹개발할 실력이면 훨씬 쉬운 GUI개발은 간단할텐데요.

Anonymous wrote:
손님 wrote:

제가 주로 사용하는 WinForm의 경우는 이야기가 다릅니다.
delegate라는 이벤트 형식을 이용하는 데, 이것으로 인해서 폼을 하나의 객체처럼 다루고, 상속할 때 부모폼에서 설정한 컨트롤들의 모든 이벤트 코딩들이 자식 폼에서도 작동하는 놀라운 모습을 보입니다.

asp.net 과 winform 의 경우가 다른데...그 이유가 델리게이트? 좀...이유가 부적절한것 같습니다. asp.net에서도 델리게이트 사용가능합니다. 이 델리게이트라는 것이 별것이 아닙니다. c/c++ 의 함수 포인터 입니다.

ASP.NET과 WinForm이 다르다는 것은 생산성을 지칭하는 겁니다.
WinForm의 생산성은 deletgate를 이용한 이벤트 덕분이라고 생각하구요.

Anonymous wrote:
손님 wrote:

지금 당장은 Mono가 큰 효용성은 없다고 보실 수도 있습니다.
그러나, C#으로 처음부터 모든 WinForm컨트롤을 구현하는 프로젝트가 상당한 속도로 진행 중입니다.
C#으로 구현된다는 말은 메모리 누수는 걱정할 필요가 없다는 이야기이고, 상당한 안정성이 예상됩니다.
C#으로 구현하면 좀 느리겠지만, 요즘 컴퓨터들이 좀 빠릅니까?
잘 될 거라고 생각합니다.
WinForm구현이 되면, 엄청난 일이 생기는 겁니다.
윈도우와 리눅스를 동시에 지원하는 프로그램을 짜는 것이 아주 용이해지므로, 기업에서 .NET으로 전산프로그램을 구현하면 윈98, 윈Me를 사용하던 컴퓨터들 여차하면 리눅스로 바꾸는 것이 가능해 집니다.
.NET으로 구현하는 GUI의 생산성이 원체 높으므로(제 경험상) 상당히 매력적인 선택이 될 수 있습니다.

mono와 닷넷은 별개로 봐야 합니다. 닷넷은 오로지 윈도우 플랫폼에 종속적입니다. 물론 소스와 IL 호환이 약간 가능할지 모르겠으나 만족할만한 수준은 어려울듯 합니다. 제 생각에 현재 윈도우와 리눅스를 지원하는 도구중 가장 만족할만한 것이 델파이/카일릭스 정도가 아닌듯 합니다.

mono만드는 곳이랑, .Net만든느 회사가 다르기 때문에 별개이긴 하지만 구현하는 스펙은 같지 않나요?
예전에 linux관련 전시회에서 MS가 Visual Studio로 개발한 ASP.NET 폼을 그대로 가져다가 Linux상의 Mono에서 그대로 돌리는 것을 시연한 적도 있습니다.

Anonymous wrote:
손님 wrote:

거기에다가 각 Visual Studio버전은 해당 ..NET버전의 개발만 가능합니다.

Visual Studio .NET 처음 버전은 .NET 1.0의 개발만 가능했습니다.
Visual Studio .NET 2003버전은 .NET 1.1의 개발만 됩니다.
Visual Studio .NET 2005버전은 .NET 2.0의 개발만 될 것입니다.
Visual Studio안에는 해당 .NET SDK가 (당연히) 들어있습니다.
이것이 의미하는 바는 거꾸로 Mono가 지원하는(목표로 하는) .NET버전에 대응하는 Visual Studio가 있으면 해당 .NET버전도 가지고 있으므로 MS가 웹사이트에서 해당 .NET버전을 지우거나 찾기 어렵도록 꼭꼭 숨겨놓아도, 이전버전의 .NET은 계속해서 사용할 수 있다는 말이 됩니다.


솔직히 위의 말씀은 도무지 잘 이해가 안되서..제가 잘못 이해하고 작성할수도 있습니다.
너무 큰 착각을 하고 계신듯 하신데 .net 기반의 개발을 할때 비주얼 스튜디오가 있어야만 가능한 것이 아닙니다. .net 을 지원하는 개발툴도 비주얼 스튜디오만 있는 것도 아니며(아시다시피 .net은 언어에 독립적이죠. 이미 볼랜드에서는 c#빌더, delphi for .net 등이 있습니다.) 에디터 하나만으로도 개발 가능합니다. 비주얼 스튜디오가 특정 버전의 닷넷 프레임워크에 종속되어 있어서...라는 말은 맞지가 않습니다. 거기다가 가장 문제가 될수 있는 소지가 닷넷은 ms의 기술이라는 것입니다. 나중에(mono가 영향력이 있을쯤...) 어떤 딴지를 걸지 알수 없는 노릇입니다.


제가 읽어봐도 요지가 뭔지 알기 어렵군요.. 죄송합니다.

제 요지는 이럽습니다.
.Net의 기본 개발환경인 Visual Studio를 가지고 있으면, 해당 되는 .Net버전을 가지고 있으며, 그 .Net버전은 고정이라는 겁니다.
MS가 숨기려고해도 숨길 수도 없고, Mono가 해당 .Net버전의 기능을 모두 구현하면 그 순간부터, crossplatform이 되는 것입니다.
WINE처럼 끝없이 쫓고 쫓기는 게임이 아니라는 겁니다.

그리고, 이론적으로 .Net의 개발은 노트패드로 해도 됩니다만...
제가 .Net을 사용하는 이유는 순전히 Visual Studio의 생산성 때문입니다.
Mono개발자들도 Visual Studio의 debugging환경에 대해서 찬사를 보내는 것을 봤습니다.
Visual Studio가 없는 .Net이 Java보다 뭐가 좋은 지 궁금하군요.

그리고, .Net의 ECMA규격은 공개표준입니다.
그리고, MS가 .Net의 확산을 위해서 '.Net을 구현하는 데 사용할 경우', MS가 가지고 있는 모든 관련 특허는 사용허가했습니다.
물론 Java라는 강력한 경쟁상대가 없었으면 MS가 그렇게 관대했을 리가 없죠.

익명 사용자의 이미지

다른 토론 주제(mono)에서 답글로 올렸던 글입니다.

어느 분이 새로운 토론의 머릿글로 올리셨는 지 모르겠습니다.

지금 읽어보니 글이 너무 엉망이군요.

읽으신 분들의 노고에 감사드립니다.

익명 사용자의 이미지

hys545 wrote:
현제 winform은 swf#으로 전환중이라고 알고 있습니다.
소스 보면 winelib하고 swf하고 같이 winfirms밑에 있습니다.
그런데 이거 시간이 걸릴거 같습니다.

swf#이 뭐죠? 새로운 언어인가요?
전 C#으로 새로 개발하는 줄 알았는 아닌가요?

hys545의 이미지

Anonymous wrote:
hys545 wrote:
현제 winform은 swf#으로 전환중이라고 알고 있습니다.
소스 보면 winelib하고 swf하고 같이 winfirms밑에 있습니다.
그런데 이거 시간이 걸릴거 같습니다.

swf#이 뭐죠? 새로운 언어인가요?
전 C#으로 새로 개발하는 줄 알았는 아닌가요?


우너래 eclipse팀에서 플랫폼 독립조적인 GUI톨킷을 자마로 만든게 swt입니다
이건 sharpdevelop침이 c#으로 다시 만들고
이걸 mono측에서 가져다 쓰,

즐린

페이지