Win32 에뮬 프로젝트들은 실패? 좌절? 진행?

kenny007one의 이미지

대표적인 Windows 프로그램을 실행하기 위한 에뮬레이터(바이너리 호환도 포함) 프로젝트가 몇개 있습니다.

가장 오래되고 대표적인 오픈 소스 프로젝트로는 Wine
그 뒤를 추격할려는 일본인들이 중심이 되었다가 지금은 흐지부지된 PEACE,
그리고 SUN에서 솔라리스에서 돌아가게 할려했던 WABI,
마지막으로 국내의 방준영씨에 의해 시작된 Mogua 라는
시작은 참 신선하고 기대가 많았지만 역시 얼마후
지금은 프로젝트 홈페이지가 없어져버린 국내의 유일무이하게 기대와 관심을 받았던 오픈 소스 프로젝트..

근데 결국엔 지금 시점에서 보면 오래되던 얼마 되지 않았더 것이던 그리 성공했다 볼수 있는 경우가 없다는 겁니다.

거의 윈도우즈의 시작과 함께 시도는 항상 있어 왔던 말이죠.

지금 어둠의 경로로 오리지날 윈도우즈의 소스코드까지 유출된 마당에 이젠 정말 똑같은 클론을 만들수 있지 않을까 생각합니다.

정녕 MS 윈도우즈와 직접 경쟁제품을 만들 방법은 과거 OS/2이후로는 이제 더 이상 나타날수 없는걸까요?

Linux는 잘해야 성공하면 대부분의 OS시장인 데스크톱 시장점유율을 어느정도 뺏어올수 있다뿐이지 직접 경쟁하여 잠식해나갈수는 없습니다.

IBM은 왜 OS/2를 더더욱 발전시켜 Windows와 직접 경쟁을 하지 않고 아예 포기하고, OS 개발기술력은 세계최고라 볼수 있는 SUN사는 데스크톱시장에 진출안하고 그나마 애플은 이제서야 x86으로 선회하여 한번 경쟁할 기미를 보일까 하는 정도일까요?

morris의 이미지

reactOS가 빠졌네요

Quote:

Linux는 잘해야 성공하면 대부분의 OS시장인 데스크톱 시장점유율을 어느정도 뺏어올수 있다뿐이지 직접 경쟁하여 잠식해나갈수는 없습니다

이렇게 생각하시는 이유가 궁금합니다.

방준영의 이미지

Mogua 프로젝트는 여전히 잘 진행되고 있습니다. 단지 몇몇 이유로 인해 처음에 생각했던 것보다 시간이 더 걸리고 있습니다만, 반드시 나온다는 사실만은 자신있게 말씀드릴 수 있습니다. :wink:

kenny007one의 이미지

morris wrote:
reactOS가 빠졌네요

Quote:

Linux는 잘해야 성공하면 대부분의 OS시장인 데스크톱 시장점유율을 어느정도 뺏어올수 있다뿐이지 직접 경쟁하여 잠식해나갈수는 없습니다

이렇게 생각하시는 이유가 궁금합니다.

당연한 얘길 왜 묻는지 의아합니다.

그럼 얼마전까지 PowerPC를 쓴 애플 매킨토시와 x86 계열 프로세서의 IBM PC가 서로 실제 직접 경쟁하는 시장을 공유한다 말하나요? ( 이젠 x86을 써서 만약 카피 프로텍션이 풀리면 직접 경쟁하는 OS로 부상할수도 있습니다만 )

경쟁은 똑같은 조건하에 같은 기준을 갖고 서로 비교가능할때 직접 경쟁가능하다라고 하는겁니다.

Linux가 아무리 뛰어나고 쓸려는 사람이 많아져봐야 Win32 어플들을 100% 서로 공유가능하여 같은 어플을 구동시키는 OS 로써 존재할때 경쟁OS라 할수 있습니다.

아니면 기존의 구축된 시장을 파이를 키워서 나눠가질순 있어도 갉아먹으면서 잠식할수는 없다는 얘기지요.

리눅스 데스크톱이 많아져봐야 그건 파이가 커져서 독립된 시장으로 커지는거지 기존의 윈도우즈 데스크탑시장을 뺏어먹어 들어가는게 아닙니다.

kenny007one의 이미지

방준영 wrote:
Mogua 프로젝트는 여전히 잘 진행되고 있습니다. 단지 몇몇 이유로 인해 처음에 생각했던 것보다 시간이 더 걸리고 있습니다만, 반드시 나온다는 사실만은 자신있게 말씀드릴 수 있습니다. :wink:

그럼 왜 프로젝트를 오픈 소스로 시작하셨음에도 중간 결과를 공개하지 않으십니까? 다시 close 프로젝트로 변경된건가요?

현재 상황과 개발되어진 소스코드를 어느정도 공개하셔야 오픈 소스 프로젝트아닌지요?

만약 현재 상황을 공개하지 않으시면 close 프로젝트로 바꾸신거로 알고 있겠습니다.

중간에 아무런 공지도 없이 사람들한테 잔뜩 기대만 불어넣고 말 바꾸신거 같아 처음에 기대했던 사람들이 지금은 상당히 실망하고 있습니다.

jedi의 이미지

win32에뮬이 리눅스에서 완벽하게 동작하면 리눅스는 망할 겁니다.

OS/2의 전례에서 알 수 있듯이 독약이죠.

그저 적당히... 동적하는 것은 좋아도 그이상이면......

그리고 윈도우용은 윈도우에서 쓰세요. 미쳤다고 윈도우용을 리눅스에서 들립니까?? 뭐 저도 미친척하고 돌리긴 하지만 차라리 윈도를 켜서 씁니다...

+++ 여기부터는 서명입니다. +++
국가 기구의 존속을 위한 최소한의 세금만을 내고, 전체 인민들이 균등한 삶을
영위할 수 있는 착취가 없는 혁명의 그날은 언제나 올 것인가!
-- 조정래, <태백산맥> 중에서, 1986년

uriel의 이미지

동영상 코덱을 이용하는 플레이어같이 wine의 결과물을 이용해서 다른 프로젝트에서 사용하는 경우도 있으니까 wine 같은 경우는 충분히 결과가 어느 정도 나온 상태라고 봐야죠. Windows NT의 NTFS.SYS를 이용해서 NT 파티션에 쓰기를 지원하는 것도 wine의 결과물을 이용하는 것이죠.

hys545의 이미지

morris wrote:
reactOS가 빠졌네요

Quote:

Linux는 잘해야 성공하면 대부분의 OS시장인 데스크톱 시장점유율을 어느정도 뺏어올수 있다뿐이지 직접 경쟁하여 잠식해나갈수는 없습니다

이렇게 생각하시는 이유가 궁금합니다.


reactos는 wine api를 사용합니다.
즉 wine에서 파생된거일 뿐..

즐린

ganadist의 이미지

reactos는 nt커널을 새로 구현한 것입니다. wine은 win32 api를 구현한 것이고요.

linux에서 glibc를 쓴다고 linux가 glibc에서 파생되었다고 이야기는 할 수 없겠죠?

----
데스크탑 프로그래머를 꿈꾸는 임베디드 삽질러

kenny007one의 이미지

jedi wrote:
win32에뮬이 리눅스에서 완벽하게 동작하면 리눅스는 망할 겁니다.

OS/2의 전례에서 알 수 있듯이 독약이죠.

그저 적당히... 동적하는 것은 좋아도 그이상이면......

그리고 윈도우용은 윈도우에서 쓰세요. 미쳤다고 윈도우용을 리눅스에서 들립니까?? 뭐 저도 미친척하고 돌리긴 하지만 차라리 윈도를 켜서 씁니다...

제 토론의 제안을 잘못 이해하셨군요. 위에 제 글을 잘 살펴보시기 바랍니다.

제 얘긴 왜 윈도우용 프로그램을 에뮬레이팅하는 프로젝트가 성공못하는지 성공할 방법은 없는지, 경쟁할 방법은 없는가이지, 윈도용 어플리케이션을 리눅스같은 타OS에서 돌려보자만 따지자가 아닙니다.

그리고 OS/2는 윈도우즈95이상의 Win32 어플을 호환시킨게 아닙니다. 윈도우즈3.1의 Win16 API입니다. Win32까지 가능했다면 OS/2가 윈도우즈95랑 직접 경쟁을 했겠지만 그 이후는 MS와 라이센스 맷은 계약이 틀려서 할수가 없는거로 압니다. MS와의 개발 라이센스는 Win16까지만 체결한거고 윈도우즈95 나온 이후 Win32이후는 아예 어떤 기술협약도 없는거로 압니다.

현재까지 Win32 API를 완전히 100%에 가깝게 바이너리 호환이던 소스 레벨 호환이던 에뮬레이팅이던 완전히 커널부터 만들던간에 완성한 적이 없었다는 것을 얘기하자는 겁니다.

그나마 가장 근접한 Wine도 너무 불안정하고 느려서 몇개되는 어플도 실제 쓸만한 수준의 성능과 속도가 안나오니 경쟁할수 없다는 얘기였습니다.

jedi의 이미지

kenny007one wrote:
jedi wrote:
win32에뮬이 리눅스에서 완벽하게 동작하면 리눅스는 망할 겁니다.

OS/2의 전례에서 알 수 있듯이 독약이죠.

그저 적당히... 동적하는 것은 좋아도 그이상이면......

그리고 윈도우용은 윈도우에서 쓰세요. 미쳤다고 윈도우용을 리눅스에서 들립니까?? 뭐 저도 미친척하고 돌리긴 하지만 차라리 윈도를 켜서 씁니다...

제 토론의 제안을 잘못 이해하셨군요. 위에 제 글을 잘 살펴보시기 바랍니다.

제 얘긴 왜 윈도우용 프로그램을 에뮬레이팅하는 프로젝트가 성공못하는지 성공할 방법은 없는지, 경쟁할 방법은 없는가이지, 윈도용 어플리케이션을 리눅스같은 타OS에서 돌려보자만 따지자가 아닙니다.

그리고 OS/2는 윈도우즈95이상의 Win32 어플을 호환시킨게 아닙니다. 윈도우즈3.1의 Win16 API입니다. Win32까지 가능했다면 OS/2가 윈도우즈95랑 직접 경쟁을 했겠지만 그 이후는 MS와 라이센스 맷은 계약이 틀려서 할수가 없는거로 압니다. MS와의 개발 라이센스는 Win16까지만 체결한거고 윈도우즈95 나온 이후 Win32이후는 아예 어떤 기술협약도 없는거로 압니다.

현재까지 Win32 API를 완전히 100%에 가깝게 바이너리 호환이던 소스 레벨 호환이던 에뮬레이팅이던 완전히 커널부터 만들던간에 완성한 적이 없었다는 것을 얘기하자는 겁니다.

그나마 가장 근접한 Wine도 너무 불안정하고 느려서 몇개되는 어플도 실제 쓸만한 수준의 성능과 속도가 안나오니 경쟁할수 없다는 얘기였습니다.


OS/2도 윈 95를 돌리는 것에 기술적인 문제는 없었다고 들었습니다.
다만 짝퉁, 아류작은 절대로 오리지날을 능가할 수 없습니다.
짝퉁의 처지는 거기서 끝이죠.

결국 win32 에뮬은 필요성이 없다는 생각입니다.
실패, 좌절, 진행 이 아닌 필요성이 없다 라고 생각합니다.

만약 리눅스도 에뮬에 전념한다면 옥소리가 그러했듯이 아무도 기억해 주지 않을 겁니다.

+++ 여기부터는 서명입니다. +++
국가 기구의 존속을 위한 최소한의 세금만을 내고, 전체 인민들이 균등한 삶을
영위할 수 있는 착취가 없는 혁명의 그날은 언제나 올 것인가!
-- 조정래, <태백산맥> 중에서, 1986년

lacovnk의 이미지

에뮬하니..

갑자기 게임기 에뮬이 생각나버렸습니다 (푸핫;; )

음.

kenny007one wrote:
지금 어둠의 경로로 오리지날 윈도우즈의 소스코드까지 유출된 마당에 이젠 정말 똑같은 클론을 만들수 있지 않을까 생각합니다.

정녕 MS 윈도우즈와 직접 경쟁제품을 만들 방법은 과거 OS/2이후로는 이제 더 이상 나타날수 없는걸까요?

Linux는 잘해야 성공하면 대부분의 OS시장인 데스크톱 시장점유율을 어느정도 뺏어올수 있다뿐이지 직접 경쟁하여 잠식해나갈수는 없습니다.

1. 윈도우즈 소스코드 유출, 일부만이라고 봤던 것 같은데.. 아닌가요?;
2. 어느정도 빼앗는게 경쟁해서 잠식아닌가요?;; 현실상 대등하지 못하다는 뜻은 이하의 답글에서 읽고 동의합니다만, "5% 하면 매니아의 잠식이고, 20%하면 경쟁상대다.." 이런식으로 딱 갈라 말하기도 어렵고, 전적으로 리눅스가 이뻐서 -o- 그렇게 믿고싶지 않아요~ ㅎㅎ 즉, 현실을 섣불리 제단해서 아예 가능성을 차단하면 토론이 이루어지기 어려운 것 같습니다. (많은 지식이 있는 분들이 그러면.. 저같은 초짜는 쫍니다 -o-; )

jedi wrote:
OS/2도 윈 95를 돌리는 것에 기술적인 문제는 없었다고 들었습니다.
다만 짝퉁, 아류작은 절대로 오리지날을 능가할 수 없습니다.
짝퉁의 처지는 거기서 끝이죠.

결국 win32 에뮬은 필요성이 없다는 생각입니다.
실패, 좌절, 진행 이 아닌 필요성이 없다 라고 생각합니다.

만약 리눅스도 에뮬에 전념한다면 옥소리가 그러했듯이 아무도 기억해 주지 않을 겁니다.

전.. 윈도 에뮬이 오락기 에뮬처럼 되면 좋겠어요 으하하하~ -o- 하드웨어가 받혀주면 속도 문제는 줄어들테고, 안정성과 기능만 확보된다면, 충분히 "사용자"는 있으리라 생각하거든요. 사용자가 있다는 것이 곧 필요성이 있다는 것 아닐까요? :)

물론, 리눅스가 오직 윈도우즈의 견제OS로서의 역할을 위해, swithing을 위한 유인책으로만 윈도우즈 에뮬을 바라보고 싶지는 않습니다. 그런 면에서 마지막 줄은 정말 의미심장하고, 동감합니다.

...하지만 결과로 보면 그렇게 될수는 있겠지요? 그런 희망을 "그건 무가치하다"라고 못밖는 것은.. 슬퍼요 흑 ㅠㅠ

어쨌든, 토론의 원 글에 의거하여 -_-; mogua는 어떻게 되가는지, 그리고 다른 프로젝트가 어떤 상황인지 궁금합니다.

솔직히 wine은 꽤 완성도 있는 편이라고 생각했었습니다. 스타도 되고, 포샵도 되고ㅎㅎㅎ;; 아무 설정 없이, 그냥 윈도우 어플 하나 까는데 실행되서 놀라기도 하고..- finale 2005, 악보 사보 프로그램입니다 - 다른 분들은 어떻게 생각하시나요?

덧. 그러고 보니, 글 제목은 에뮬의 진행상황에 대해서.. 라고 있는데, 글 내용은 정작, 에뮬은 필요하지 않은 것 아닌가! 라고 되어 있어서 살짝 헷갈리네요^^; 하지만, 에뮬이 과연 필요한가! 등등에 대한 위분들의 토론과 비슷한 것을 여러번 본 적이 있는 것 같아서.. 전자쪽으로 한번 끝을 살짝 마무리해봅니다 ㅎㅎ

kenny007one의 이미지

jedi wrote:
OS/2도 윈 95를 돌리는 것에 기술적인 문제는 없었다고 들었습니다.
다만 짝퉁, 아류작은 절대로 오리지날을 능가할 수 없습니다.
짝퉁의 처지는 거기서 끝이죠.

결국 win32 에뮬은 필요성이 없다는 생각입니다.
실패, 좌절, 진행 이 아닌 필요성이 없다 라고 생각합니다.

만약 리눅스도 에뮬에 전념한다면 옥소리가 그러했듯이 아무도 기억해 주지 않을 겁니다.

정말 황당한 이론이시군요. 갑자기 옥소리가 왜 나옵니까?

그럼 그런식으로 따져보면 리눅스는 왜 Unix 를 최대한 참조해서 만들어지고 POSIX 표준을 따르며 기존의 유닉스들을 최대한 많이 바이너리와 소스코드레벨에서 호환되도록 하는 노력은 왜 했다 봅니까? 하물며 폐쇄OS인 맥OS조차도 BSD커널을 가져다가 쓰는 현실에서 필요성이 없다라, 그럼 항상 OS만들땐 기존의 호환성은 쓰레기통에 집어넣고 기존의 코드는 한줄도 참고하면 안되겠군요. 모두 새롭게, 커널도, 컴파일러도 새로운거 써서 개발하는..

님은 그게 가능하다고 보십니까? 기존의 지배하고 있는 시장 호환성을 처음부터 깡그리 무시하고 나간다는게?

그럼 64비트의 현재 대체 기술인 x86-64가 왜 AMD가 만들어 놓고 인텔이 자존심 숙이며 기존의 IA64의 아이테니움을 실패인정하며 따라가나요?

윈도우즈조차도 NT커널은 데이빗 커틀러가 VMS커널의 기술을 좀 더 발전시켜 이식한거에 불과합니다.

님이 그런말대로라면 Mogua에 열정적으로 개발하고 계시는 방준영님은 옥소리처럼 망하게 된다는 얘기군요. 맞습니까?

오만한 리눅서의 이미지

kenny007one wrote:
jedi wrote:
OS/2도 윈 95를 돌리는 것에 기술적인 문제는 없었다고 들었습니다.
짝퉁의 처지는 거기서 끝이죠.

결국 win32 에뮬은 필요성이 없다는 생각입니다.
실패, 좌절, 진행 이 아닌 필요성이 없다 라고 생각합니다.

만약 리눅스도 에뮬에 전념한다면 옥소리가 그러했듯이 아무도 기억해 주지 않을 겁니다.

정말 황당한 이론이시군요. 갑자기 옥소리가 왜 나옵니까?

"다만 짝퉁, 아류작은 절대로 오리지날을 능가할 수 없습니다."
이건 98%쯤은 맞는 말이지만, 2%쯤은 예외도 있기 때문에
반드시 실패한다라는 말보다는 실패할 가능성이 매우 높다라는 말로
수용하겠습니다.

저도 리눅스가 win32 에뮬에 전념하거나 혹은 완벽한 win32 클론을
목표로 한다면, 실패할 확률이 높다고 봅니다.

단지, 리눅스의 부족한 부분을 커버하는 측면에서 이용한다면,
충분하리라 생각합니다.

그리고, 리눅스는 리눅스 자신만의 영역과 색깔을 가지고
시장에 진입해도 어느정도는 승산이 있을 만큼 성장했다고 봅니다.

:evil: :lol:

1day1의 이미지

좋은 토론으로 이어졌으면 좋겠습니다만, 플레임의 소지가 다분하네요.
조금 감정적인 어조는 삼가시는것이 좋을 듯 합니다.

리눅스 vs 윈도우 의 관점이 아닌, win32 에뮬 자체에 대한 토론이 되는 것이 좋겠습니다.

전 개인적으로 vmware , xen 같은 종류(win32에뮬과는 다르지만..) 가 마음에 들지만,
win32 에뮬도 어느수준까지는 필요하다고 생각이 듭니다.

F/OSS 가 함께하길..

kida의 이미지

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

kenny007one wrote:

지금 어둠의 경로로 오리지날 윈도우즈의 소스코드까지 유출된 마당에 이젠 정말 똑같은 클론을 만들수 있지 않을까 생각합니다.

유출된 소스 코드를 이용하여 프로그램을 작성할 경우,
추후에 문제가 될 소지가 크므로,
많은 프로젝트들은 제작자들에게 유출된 소스를 보지 말것을 요구하고 있습니다.

안경 미소녀가 좋아~!

ganadist의 이미지

kenny007one wrote:

하물며 폐쇄OS인 맥OS조차도 BSD커널을 가져다가 쓰는 현실에서 필요성이 없다라...

많은 분들이 헷깔려하시는데 애플의 커널인 darwin의 라이센스는 Apple Public Source License으로, OSI에게 인증을 받은 오픈소스 라이센스입니다. 그리고 BSD기반이 아니라 Mach라는 Microkernel기반입니다.

그위에 올라가는 기본 라이브러리와 ls, mount, ps 같은 기본적인 시스템 유틸리티들은 BSD의 것을 사용하고 있고 그것을 지원하는 시스템 콜 때문에 BSD커널 Extention이 존재하며, gcc나 make같은 각종 개발도구는 GNU의 것들을 사용합니다.

----
데스크탑 프로그래머를 꿈꾸는 임베디드 삽질러

방준영의 이미지

kenny007one wrote:
방준영 wrote:
Mogua 프로젝트는 여전히 잘 진행되고 있습니다. 단지 몇몇 이유로 인해 처음에 생각했던 것보다 시간이 더 걸리고 있습니다만, 반드시 나온다는 사실만은 자신있게 말씀드릴 수 있습니다. :wink:

그럼 왜 프로젝트를 오픈 소스로 시작하셨음에도 중간 결과를 공개하지 않으십니까? 다시 close 프로젝트로 변경된건가요?

현재 상황과 개발되어진 소스코드를 어느정도 공개하셔야 오픈 소스 프로젝트아닌지요?

만약 현재 상황을 공개하지 않으시면 close 프로젝트로 바꾸신거로 알고 있겠습니다.

중간에 아무런 공지도 없이 사람들한테 잔뜩 기대만 불어넣고 말 바꾸신거 같아 처음에 기대했던 사람들이 지금은 상당히 실망하고 있습니다.


중간 결과를 공개하지 않는 이유는 유감스럽게도 Mogua는 더이상 오픈소스 프로젝트가 아니라서 그렇습니다. 여기에는 불가피한 이유가 있는데, 자세한 것은 첫번째 스냅샷이 나올 때쯤 말씀드릴 수 있을 것 같습니다. 공지 없이 정책을 변경한 것에 실망하셨다면 사과드립니다만, 결과물만은 만족을 드릴 수 있도록 오늘도 밤낮으로 열심히 작업중이라는 점은 믿어 주세요. :wink:
방준영의 이미지

ganadist wrote:
kenny007one wrote:

하물며 폐쇄OS인 맥OS조차도 BSD커널을 가져다가 쓰는 현실에서 필요성이 없다라...

많은 분들이 헷깔려하시는데 애플의 커널인 darwin의 라이센스는 Apple Public Source License으로, OSI에게 인증을 받은 오픈소스 라이센스입니다. 그리고 BSD기반이 아니라 Mach라는 Microkernel기반입니다.


커널 소스를 받아보시면 아시겠지만 트리 이름이 아예 bsd입니다. :roll:
방준영의 이미지

글제목도 그렇고 전체 분위기가 좀 오해의 소지가 있기에 잠깐 설명을 드리자면 Mogua는 윈도 에뮬이 아닙니다. 윈도 에뮬이라는 것은 윈도 환경을 윈도가 아닌 환경(리눅스같은)에서 흉내낸다는 것을 의미하는데, Mogua는 윈도 환경을 커널 수준에서부터 그대로 따르고 있습니다. DR-DOS를 MS-DOS 클론이라고 부르기는 해도 MS-DOS 에뮬이라고 부르는 사람은 없듯이, 그것과 마찬가지라고 생각하시면 되겠습니다.

윈도 에뮬이건 윈도 호환 OS건 통칭할 때는 윈도 애플리케이션 실행 환경이 더 적절하지 않을까 싶네요. 줄여서 윈도 실행 환경...

CY71의 이미지

밴더풀이나 퍼시피카 나오면 토론 자체가 무의미할 듯 합니다.

XEN 의 경우에는 하드웨어적인 지원이 없다면 Guest OS 의 수정이 필요하지만, 하드웨어적으로 지원한다면 Guest OS 수정이 필요없다고 하더군요. 이미 인텔에서 밴더풀 엔지니어링 샘플을 내놓은 상황이고, AMD 에서도 퍼시피카 열심히 개발 중입니다. 이 기술들을 채택한 CPU 본격 발매되면 윈도 에뮬은 그 차원이 달라질 듯 합니다.

하드웨어 차원에서 가상화 기술을 지원하면, vmware 나 버츄얼PC 등의 기존 에뮬 소프트웨어보다 월등한 속도로 다른 OS 를 돌릴 수 있습니다. 리눅스의 경우에는 XEN 환경에서 네이티브의 75% 까지 나옵니다. 리눅스 기반하에 윈도를 Guest OS 로써 동시에 작동시킬 수 있게 되는 건데... 이렇게 되면 wine 같은 소프트는 영향력이 많이 줄겠죠. 문제는 역시 밴더풀이나 퍼시피카 지원하는 CPU 를 새로 구입할 돈이겠죠 ㅡ_ㅡ 아주 비쌀 것으로 예상되고 있으니까요.

지리즈의 이미지

CY71 wrote:
밴더풀이나 퍼시피카 나오면 토론 자체가 무의미할 듯 합니다.

XEN 의 경우에는 하드웨어적인 지원이 없다면 Guest OS 의 수정이 필요하지만, 하드웨어적으로 지원한다면 Guest OS 수정이 필요없다고 하더군요. 이미 인텔에서 밴더풀 엔지니어링 샘플을 내놓은 상황이고, AMD 에서도 퍼시피카 열심히 개발 중입니다. 이 기술들을 채택한 CPU 본격 발매되면 윈도 에뮬은 그 차원이 달라질 듯 합니다.

하드웨어 차원에서 가상화 기술을 지원하면, vmware 나 버츄얼PC 등의 기존 에뮬 소프트웨어보다 월등한 속도로 다른 OS 를 돌릴 수 있습니다. 리눅스의 경우에는 XEN 환경에서 네이티브의 75% 까지 나옵니다. 리눅스 기반하에 윈도를 Guest OS 로써 동시에 작동시킬 수 있게 되는 건데... 이렇게 되면 wine 같은 소프트는 영향력이 많이 줄겠죠. 문제는 역시 밴더풀이나 퍼시피카 지원하는 CPU 를 새로 구입할 돈이겠죠 ㅡ_ㅡ 아주 비쌀 것으로 예상되고 있으니까요.

소프트웨어 구입비는 논외입니까?

사실 wine을 사용함의 장점은 추가로 운영체제 비용을 지불할 필요가 없는 것도 있습니다.

EULA를 요기조기 피해가면서, 어떤 부분에서는 매우 느리긴 해도 쓸만한 M$클론으로
바꾸어 주기도 하죠.

밴더풀이나 퍼시피카가 나오면,
음... 그럼 Mogua가 활성화 되겠군요!!

There is no spoon. Neo from the Matrix 1999.

다크슈테펜의 이미지

약간은 비관적입니다.우선 지금은 소위 Win32에서 닷넷으로 넘어가는 시기입니다.비스타에서 닷넷으로 바로 넘어가기가 힘들었는 지 몰라도 비스타 다음 버전이나 서비스팩에서는 닷넷이 기본으로 될수도 있습니다.
그리고 지금 현재 쓸만한 프로그램은 거의 대부분이 엑스피 이상입니다.마소 오피스를 비롯해서 개발툴이나 그리고 포토샵 CS2버전이나 엑스피 이상입니다.심지어는 이번 MSN 메신저 최신 버전도 윈 2000조차도 지원하지 않습니다.
그런 상황에 현재 윈 98 관련 어플도 안정적으로 돌릴수 있을까 말까 한 상황에서 비스타가 출시되면 바로 마소는 소프트웨어 상한선을 비스타로 잡을 겁니다.점차 그렇게 나가겠지요...?
와인이 개발 되는동안 마소는 넋놓고 가만이 있는 것이 절대로 아닙니다.
마소도 와인 개발 하는 동안 역시 윈도우즈를 개발하고 있고 비스타가 출시되면 엑스피 죽이기에 나설겁니다.지금 엑스피에서 돌아가는 어플 돌릴수 있다고 해도 비스타 나오면 또 다른 포맷 향상된 기능이라는 미명하에 새로운 어플을 강요할것입니다.그게 현재 어플과 완전히 호환된다는 보장이 없습니다.
PS:개발자분들에게 의욕상실이 될수도 있을 겁니다.하지만 제 생각에는 윈도우 어플 보다는 리눅스 어플이 더 많이 개발되는게 더욱 바람직하다고 생각합니다.그게 더욱 마소와 전투에서 승산이 있을 것 같습니다.
닷넷은 모노로 돌릴수 있다고 주장하시는 분들은 없기를 바랍니다.
닷넷도 지금 버전업을 하고 있으며 닷넷의 언어도 지금의 C#이나 C++이 아닌 C오메가가 그런것에 대한 연구도 마소는 진행하고 있습니다.

인생이란게 다 그런게 아니겠어요....? 뭘(?)
http://schutepen.egloos.com

fibonacci의 이미지

OS 추가구입이 필요하긴 하지만 QEMU란 것도 있지요.

QEMU 그 자체는 Native에 비하여 5배이상 느리니까 실용성은 크지 않지만, 최근에 QEMU Accelerator 라는 것이 나왔는데 이를 이용하면 Native에 비하여 1~2배 느린 정도로 이용할수 있다 합니다.

http://www.qemu.org/qemu-accel.html

버전 0.7.1 이상부터 accelerator를 쓸수 있는 것 같네요. 커널 모듈의 형태로 들어가는 것 같습니다. 아쉬운 점이 있다면 qemu-accelerator는 오픈소스의 형태로 개발되는 것은 아닌 것 같고 host os가 x86 linux에서만 가능합니다.

저는 Debian sid의 0.7.0을 쓰고 있어 아직 QEMU accerator를 경험하지는 못했는데... Native에 비해 1-2배 정도라면 꽤 쓸만하겠지요.

No Pain, No Gain.

fender의 이미지

제가 볼 때 Wine의 유용성은 리눅스가 데스크탑 시장에서 윈도우즈와 경쟁을 한다고 할 때 일부 대체할 만한 리눅스 응용프로그램이 없는 영역에 대해 리거시 윈도우즈 응용프로그램을 에뮬레이션 해서 구동하게 해서 리눅스로의 전환을 돕는 정도입니다.

물론 QEMU나 Vmware를 쓰는 방법도 있지만 이는 어차피 윈도우즈 라이센스를 필요로 하기 때문에 리눅스로의 전환을 권장하는 입장에서는 Wine 등의 Win32 API 수준의 에뮬레이션이 더 바람직한 방법이라고 봅니다.

모노의 경우도 어쩌면 이런 점에서 닷넷 응용프로그램에 대해 Wine의 역할을 할 수 있을지도 모르지만 일단 최소한 WinForms 구현이라도 쓸만하게 나온 다음에 가능성을 이야기할 수 있지 않을까 싶군요.

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

girneter의 이미지

방준영 wrote:
자세한 것은 첫번째 스냅샷이 나올 때쯤 말씀드릴 수 있을 것 같습니다. 공지 없이 정책을 변경한 것에 실망하셨다면 사과드립니다만, 결과물만은 만족을 드릴 수 있도록 오늘도 밤낮으로 열심히 작업중이라는 점은 믿어 주세요. :wink:

첫번째 스냅샷을 언제쯤으로 계획하고 계신가요?
기대하고 있습니다

개념없는 초딩들은 좋은 말로 할때 DC나 웃대가서 놀아라. 응?

hys545의 이미지

방준영 wrote:
ganadist wrote:
kenny007one wrote:

하물며 폐쇄OS인 맥OS조차도 BSD커널을 가져다가 쓰는 현실에서 필요성이 없다라...

많은 분들이 헷깔려하시는데 애플의 커널인 darwin의 라이센스는 Apple Public Source License으로, OSI에게 인증을 받은 오픈소스 라이센스입니다. 그리고 BSD기반이 아니라 Mach라는 Microkernel기반입니다.


커널 소스를 받아보시면 아시겠지만 트리 이름이 아예 bsd입니다. :roll:

mach가 원래 bsd진영에서 개발한겁니다.

즐린

hys545의 이미지

fender wrote:
제가 볼 때 Wine의 유용성은 리눅스가 데스크탑 시장에서 윈도우즈와 경쟁을 한다고 할 때 일부 대체할 만한 리눅스 응용프로그램이 없는 영역에 대해 리거시 윈도우즈 응용프로그램을 에뮬레이션 해서 구동하게 해서 리눅스로의 전환을 돕는 정도입니다.

물론 QEMU나 Vmware를 쓰는 방법도 있지만 이는 어차피 윈도우즈 라이센스를 필요로 하기 때문에 리눅스로의 전환을 권장하는 입장에서는 Wine 등의 Win32 API 수준의 에뮬레이션이 더 바람직한 방법이라고 봅니다.

모노의 경우도 어쩌면 이런 점에서 닷넷 응용프로그램에 대해 Wine의 역할을 할 수 있을지도 모르지만 일단 최소한 WinForms 구현이라도 쓸만하게 나온 다음에 가능성을 이야기할 수 있지 않을까 싶군요.

지금 mono의 winform은 기존의 win32에서 swt기반으로 전환중입니다.
기다리면 쓸만한게 나올겁니다.

즐린

jedi의 이미지

kenny007one wrote:
jedi wrote:
OS/2도 윈 95를 돌리는 것에 기술적인 문제는 없었다고 들었습니다.
다만 짝퉁, 아류작은 절대로 오리지날을 능가할 수 없습니다.
짝퉁의 처지는 거기서 끝이죠.

결국 win32 에뮬은 필요성이 없다는 생각입니다.
실패, 좌절, 진행 이 아닌 필요성이 없다 라고 생각합니다.

만약 리눅스도 에뮬에 전념한다면 옥소리가 그러했듯이 아무도 기억해 주지 않을 겁니다.

정말 황당한 이론이시군요. 갑자기 옥소리가 왜 나옵니까?

그럼 그런식으로 따져보면 리눅스는 왜 Unix 를 최대한 참조해서 만들어지고 POSIX 표준을 따르며 기존의 유닉스들을 최대한 많이 바이너리와 소스코드레벨에서 호환되도록 하는 노력은 왜 했다 봅니까? 하물며 폐쇄OS인 맥OS조차도 BSD커널을 가져다가 쓰는 현실에서 필요성이 없다라, 그럼 항상 OS만들땐 기존의 호환성은 쓰레기통에 집어넣고 기존의 코드는 한줄도 참고하면 안되겠군요. 모두 새롭게, 커널도, 컴파일러도 새로운거 써서 개발하는..

님은 그게 가능하다고 보십니까? 기존의 지배하고 있는 시장 호환성을 처음부터 깡그리 무시하고 나간다는게?

그럼 64비트의 현재 대체 기술인 x86-64가 왜 AMD가 만들어 놓고 인텔이 자존심 숙이며 기존의 IA64의 아이테니움을 실패인정하며 따라가나요?

윈도우즈조차도 NT커널은 데이빗 커틀러가 VMS커널의 기술을 좀 더 발전시켜 이식한거에 불과합니다.

님이 그런말대로라면 Mogua에 열정적으로 개발하고 계시는 방준영님은 옥소리처럼 망하게 된다는 얘기군요. 맞습니까?


네! 망한다고 생각합니다.

에뮬과 위의 예를 드신 것과는 차이가 많습니다. 예를 드신것은 제곰 받은 부품으로 완제품을 만든 예라고 볼 수 있죠. 하지만 에뮬은 완제품을 보고 흉내내는 수준이라고 생각하죠.

어플리케이션 공급사에서 윈32 클론에서도 동작하는 것을 보증해줄까요? 문제가 생기면 어떻게 해결하죠?
시장에서 판매도 힘들고 사용하는 사람의 부담도 너무 많습니다..

성공하려면 MS의 공식 지원을 받거나 계약을 하고 지원받으며 한다면 가능하죠...

+++ 여기부터는 서명입니다. +++
국가 기구의 존속을 위한 최소한의 세금만을 내고, 전체 인민들이 균등한 삶을
영위할 수 있는 착취가 없는 혁명의 그날은 언제나 올 것인가!
-- 조정래, <태백산맥> 중에서, 1986년

방준영의 이미지

hys545 wrote:
mach가 원래 bsd진영에서 개발한겁니다.

BSD 스타일 라이센스를 따르는 것과 BSD 진영에서 개발한 것은 별개의 문제입니다. 그렇게 친다면 X나 아파치도 BSD 진영에서 만들었다고 해야겠지요.

이런 불필요한 논쟁보다 그냥 커널 소스를 훑어보고 직접 확인하는 게 빠를 것 같습니다.

pynoos의 이미지

MacOS와 MacOS X에 대한 mach, bsd 이야기는

http://en.wikipedia.org/wiki/Mac_OS_X_history
http://en.wikipedia.org/wiki/Mac_OS_history
http://en.wikipedia.org/wiki/Darwin_%28operating_system%29

위 세 URL을 참조하자면, MacOS X history에

Quote:
During this time the lower layers of the operating system (the Mach kernel and the BSD layers on top of it), were re-packaged and released under an open source license as Darwin.

커널은 mach고 그 위에 BSD layer가 있다는 군요.

방준영의 이미지

pynoos wrote:
MacOS와 MacOS X에 대한 mach, bsd 이야기는

http://en.wikipedia.org/wiki/Mac_OS_X_history
http://en.wikipedia.org/wiki/Mac_OS_history
http://en.wikipedia.org/wiki/Darwin_%28operating_system%29

위 세 URL을 참조하자면, MacOS X history에

Quote:
During this time the lower layers of the operating system (the Mach kernel and the BSD layers on top of it), were re-packaged and released under an open source license as Darwin.

커널은 mach고 그 위에 BSD layer가 있다는 군요.


Mac OS X 커널은 Mach와 BSD 커널이 혼합된 상태로 이루어져 있고, 비중으로 따지면 오리지널 BSD 라이센스가 붙어있는 소스 파일이 Mach 라이센스가 붙어있는 파일보다 훨씬 많습니다. 구조적으로 보면 몇몇 커널 서브시스템은 Mach에서 가져왔고, 몇몇 서브시스템은 BSD에서 가져왔습니다. Mach 위에 BSD 레이어를 쌓은 구조가 아닙니다(초기 개발 단계에서는 그랬는지 몰라도).

이와 같은 오해는 아마도 커널의 개념 차이에서 온 것 같습니다. 원래 Mach 커널은 커널 안에 스레드 지원, 메시지 전달, 메모리 관리자 같은 필수적인 기능만 들어 있고 파일 시스템이나 특정 OS 구조에 의존하는 시스템콜 같은 기능은 별도의 외부 프로세스(서버)를 통해 구현하는 마이크로커널 방식입니다. 가령 Mach를 가지고 유닉스 호환 OS를 만든 경우(GNU처럼) 유닉스 시스템콜을 서브시스템간 메시지로 변환해주는 레이어가 커널 외부에 따로 있고, UFS같은 파일시스템 서버 프로세스도 커널 밖에 따로 존재합니다(GNU/허드를 써보신 분들은 파일시스템 트랜슬레이터를 기억하실 겁니다). 그런데 이렇게 만들다보니 정작 제일 중요한 성능이 심각하게 떨어지는 바람에 애플이 Mac OS X를 개발하면서(NeXT에서부터 그랬는지도 모르겠습니다만) 마이크로커널과 유저모드 서버들을 도로 모놀리딕 커널로 합쳐버렸거든요. 따라서 현재 구조는 단지 Mach에서 몇몇 코드를 가져왔을 뿐 전체적으로는 BSD 커널과 훨씬 유사합니다.

Fe.head의 이미지

아류들은 살기 힘들다 라는 말에 동의 합니다.

amd가 intel 꽁무늬만 따라 다니면서

같은 클럭에서 INTEL보다 좋은 성능이나며 가격또한 싸도 제대로 팔리지 않았죠.

amd가 x86-64 라는것을 내 놓으면서 intel cpu와 차별화를 내세워 성공한것이라고 생각합니다.

따라가는것보다는 차이점을 내 세워가는것이 더 낳다고 생각합니다.

리눅스 또한 처음 나왔을때 PC에서 리눅스가 UNIX환경을 지원했다는 점에서 성공했다고 생각합니다.

고작 블로킹 하나, 고작 25점 중에 1점, 고작 부활동
"만약 그 순간이 온다면 그때가 네가 배구에 빠지는 순간이야"

정태영의 이미지

fehead wrote:
아류들은 살기 힘들다 라는 말에 동의 합니다.

amd가 intel 꽁무늬만 따라 다니면서

같은 클럭에서 INTEL보다 좋은 성능이나며 가격또한 싸도 제대로 팔리지 않았죠.

amd가 x86-64 라는것을 내 놓으면서 intel cpu와 차별화를 내세워 성공한것이라고 생각합니다.

따라가는것보다는 차이점을 내 세워가는것이 더 낳다고 생각합니다.

리눅스 또한 처음 나왔을때 PC에서 리눅스가 UNIX환경을 지원했다는 점에서 성공했다고 생각합니다.

x86 관련해서는 instruction set 등이 명확하게 드러나 있었지만 winapi 는 다릅니다... 문서화 되지 않은 부분이 상당히 많습니다...

ms-windows 호환 플랫폼을 만든다고 하더라도 위에 다른 분이 얘기하셨듯이... 정상적으로 애플리케이션이 돌지 않을 경우 누가 책임을 져 줄까요 ;)

그리고 그냥 윈도우 클론에다가 오픈소스도 아닌 경우라면 그다지 관심이 가지는 않을 듯 하군요...

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

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

jongwooh의 이미지

방준영 wrote:
따라서 현재 구조는 단지 Mach에서 몇몇 코드를 가져왔을 뿐 전체적으로는 BSD 커널과 훨씬 유사합니다.

방준영님 말씀대로 사실 Mach 자체는 별거 없습니다. 마이크로커널이란게 상용 RTOS하고 대단히 유사하거든요. 작고 빠른 코어 크기에, 태스크 매니지먼트(스케줄링) 하고 가상메모리만 들어있어서 하다못해 디바이스 드라이버도 커널과 별개의 유저 스페이스에서 돌아가는...

아뭏든 마이크로커널이 90년대 초반에 유연한 설계라고 한창 떴었지만 너무 파일시스템, 디바이스 드라이브들까지 모듈을 세분화시켜놓다 보니 실제 구현에서는 모듈간 copy overhead가 하도 심해졌다고 해서 지금은 거의 안 쓰는 추세죠.

조단 허바드씨가 애플에 스카우트 된게 아마 FreeBSD 3.x 때쯤인듯 한데... 2.X대에서 FreeBSD의 메모리 관리 메카니즘이 Mach VM 을 도입한 것으로 알고 있습니다만, 지금 Mac OS X 는 FreeBSD 3.X로부터의 메이저 브랜치로 취급하는게 제일 가까운 분류라 합니다.

실제 아이북 한대를 취미삼아 사서 한 6개월 쓸때 MacOS를 깔아보니 UI는 좋지만 콘솔 터미널 열고 들여다보면 아주 오래된 BSD 변종 느낌이 팍팍 나긴 합니다. :wink:

you must know the power of dark side.

jongwooh의 이미지

jedi wrote:

네! 망한다고 생각합니다.

에뮬과 위의 예를 드신 것과는 차이가 많습니다. 예를 드신것은 제곰 받은 부품으로 완제품을 만든 예라고 볼 수 있죠. 하지만 에뮬은 완제품을 보고 흉내내는 수준이라고 생각하죠.

어플리케이션 공급사에서 윈32 클론에서도 동작하는 것을 보증해줄까요? 문제가 생기면 어떻게 해결하죠?
시장에서 판매도 힘들고 사용하는 사람의 부담도 너무 많습니다..

성공하려면 MS의 공식 지원을 받거나 계약을 하고 지원받으며 한다면 가능하죠...

Windows를 쓰지 않으면서도 Win32 어플리케이션을 작동하려는 환경으로서 Mogua를 만드는건데 MS로부터 공식지원이나 계약을 왜 해야 하는지 설득력은 부족하다고 봅니다. MS가 해줄리도 없다고 봅니다만.

제가 보기엔 오히려 이런 시나리오가 보이는군요. Mogua가 잘 돌고, 쓸만하다고 입증되면 Mogua를 퇴출시키기 위해 먼저 소송을 걸어보고, 그게 잘 안될거 같으면 모구아를 포기하는 댓가로 방준영님을 연봉 수십억에 고용할 것 같습니다 :twisted:

Windows나 MS-DOS도 MS가 자기 힘으로만 100% 다 만든거 아닙니다. MS-DOS는 CP/M 베낀 OS의 소스코드를 사서 시작한것이고, Windows는 IBM에 파견한 OS/2 개발팀이 복귀해서 만든것입니다.

이제와서 그런 초창기 환경을 말하긴 좀 그렇긴 합니다만, 오리지날이 아니라면 쓰지 않겠다, 또는 쓸 이유가 없다라는식의 언급은 기술과 환경의 개선이나 진보에 대한 노력을 필요 이상으로 폄하한다고 보입니다.

거기서 조금 더 나가면 MS의 기득권 옹호 차원으로까지 비칠수도 있겠습니다. 흔히 그러지 않습니까. MS는 일반 기업이 아니라 세금걷는거고 (윈도우 요금이 PC세~), 인텔과 삼성도 보통 기업이 아니라 조폐창 (CPU와 램을 현금 찍듯 찍어내는~) 거라고요.

you must know the power of dark side.

jedi의 이미지

jwhan wrote:
Windows를 쓰지 않으면서도 Win32 어플리케이션을 작동하려는 환경으로서 Mogua를 만드는건데 MS로부터 공식지원이나 계약을 왜 해야 하는지 설득력은 부족하다고 봅니다. MS가 해줄리도 없다고 봅니다만.

제가 보기엔 오히려 이런 시나리오가 보이는군요. Mogua가 잘 돌고, 쓸만하다고 입증되면 Mogua를 퇴출시키기 위해 먼저 소송을 걸어보고, 그게 잘 안될거 같으면 모구아를 포기하는 댓가로 방준영님을 연봉 수십억에 고용할 것 같습니다 :twisted:

Windows나 MS-DOS도 MS가 자기 힘으로만 100% 다 만든거 아닙니다. MS-DOS는 CP/M 베낀 OS의 소스코드를 사서 시작한것이고, Windows는 IBM에 파견한 OS/2 개발팀이 복귀해서 만든것입니다.

이제와서 그런 초창기 환경을 말하긴 좀 그렇긴 합니다만, 오리지날이 아니라면 쓰지 않겠다, 또는 쓸 이유가 없다라는식의 언급은 기술과 환경의 개선이나 진보에 대한 노력을 필요 이상으로 폄하한다고 보입니다.

거기서 조금 더 나가면 MS의 기득권 옹호 차원으로까지 비칠수도 있겠습니다. 흔히 그러지 않습니까. MS는 일반 기업이 아니라 세금걷는거고 (윈도우 요금이 PC세~), 인텔과 삼성도 보통 기업이 아니라 조폐창 (CPU와 램을 현금 찍듯 찍어내는~) 거라고요.


모구아가 아니라 모과 겠죠. 아닌가요? 뭐 중요한 것은 아니고요.

제 주장은 명확합니다. 편법으로 돌리기 위해 노력하는 것 보다 리눅스용을 개발할 것을 요구하는 것이 훨씬 좋다라고 생각합니다.
그래서 IE도 리눅스용을 만들어 달라고 요구 하는 것도 좋다고 생각합니다. 불여우 보다 성능과 기능만 좋다면 당연히 사용하겠습니다.

기본 OS를 리눅스로 팔거나 OS가 없는 PC의 판매도 많이 생겨야죠.
지금도 있지 않나요? 이런 선택의 기회만 준다면 충분하다고 생각합니다.

+++ 여기부터는 서명입니다. +++
국가 기구의 존속을 위한 최소한의 세금만을 내고, 전체 인민들이 균등한 삶을
영위할 수 있는 착취가 없는 혁명의 그날은 언제나 올 것인가!
-- 조정래, <태백산맥> 중에서, 1986년

다크슈테펜의 이미지

jedi wrote:
jwhan wrote:
Windows를 쓰지 않으면서도 Win32 어플리케이션을 작동하려는 환경으로서 Mogua를 만드는건데 MS로부터 공식지원이나 계약을 왜 해야 하는지 설득력은 부족하다고 봅니다. MS가 해줄리도 없다고 봅니다만.

제가 보기엔 오히려 이런 시나리오가 보이는군요. Mogua가 잘 돌고, 쓸만하다고 입증되면 Mogua를 퇴출시키기 위해 먼저 소송을 걸어보고, 그게 잘 안될거 같으면 모구아를 포기하는 댓가로 방준영님을 연봉 수십억에 고용할 것 같습니다 :twisted:

Windows나 MS-DOS도 MS가 자기 힘으로만 100% 다 만든거 아닙니다. MS-DOS는 CP/M 베낀 OS의 소스코드를 사서 시작한것이고, Windows는 IBM에 파견한 OS/2 개발팀이 복귀해서 만든것입니다.

이제와서 그런 초창기 환경을 말하긴 좀 그렇긴 합니다만, 오리지날이 아니라면 쓰지 않겠다, 또는 쓸 이유가 없다라는식의 언급은 기술과 환경의 개선이나 진보에 대한 노력을 필요 이상으로 폄하한다고 보입니다.

거기서 조금 더 나가면 MS의 기득권 옹호 차원으로까지 비칠수도 있겠습니다. 흔히 그러지 않습니까. MS는 일반 기업이 아니라 세금걷는거고 (윈도우 요금이 PC세~), 인텔과 삼성도 보통 기업이 아니라 조폐창 (CPU와 램을 현금 찍듯 찍어내는~) 거라고요.


모구아가 아니라 모과 겠죠. 아닌가요? 뭐 중요한 것은 아니고요.

제 주장은 명확합니다. 편법으로 돌리기 위해 노력하는 것 보다 리눅스용을 개발할 것을 요구하는 것이 훨씬 좋다라고 생각합니다.
그래서 IE도 리눅스용을 만들어 달라고 요구 하는 것도 좋다고 생각합니다. 불여우 보다 성능과 기능만 좋다면 당연히 사용하겠습니다.

기본 OS를 리눅스로 팔거나 OS가 없는 PC의 판매도 많이 생겨야죠.
지금도 있지 않나요? 이런 선택의 기회만 준다면 충분하다고 생각합니다.


마소에서 그래 줄리도 없거니와 설사 해준다고 해도 퍼포먼스는 기대 안하는 게 좋습니다.
맥오에스에서 돌아가는 마소제 어플만 봐도 느낌이 와 닿을 것입니다.

인생이란게 다 그런게 아니겠어요....? 뭘(?)
http://schutepen.egloos.com

creativeidler의 이미지

Quote:
편법으로 돌리기 위해 노력하는 것 보다 리눅스용을 개발할 것을 요구하는 것이 훨씬 좋다라고 생각합니다.
그래서 IE도 리눅스용을 만들어 달라고 요구 하는 것도 좋다고 생각합니다.

문제는 요구한다고 만들어주는 게 아니라는 겁니다. 그리고 적지 않은 리눅스 유저들이 리눅스에서 윈도우 프로그램들을 돌렸으면 하는 소망을 품고 있습니다. 윈도우 실행 환경 프로젝트들은 그런 소망을 담고 움직이는 것이죠. 리눅서들이 원해서, 그리고 리눅서들이 자원해서 나서서 만들어가는 걸 두고 좋다 아니다를 논하는 것은 좀 이상하다는 생각이 드는군요. 시장의 요구에 충실히 따르고 있는 것 뿐입니다.

그리고, 전 개인적으로 리눅서에서 윈도우 XP 애플리케이션이 정말 완벽히 구동된다면 리눅스의 점유율이 급속히 높아질 수도 있다고 봅니다. 일반 사용자는 몰라도 기업에서는 윈도 애플리케이션 다 쓸 수 있다면 비싼 돈 주고 윈도우 살 이유가 없어지죠.

jongwooh의 이미지

Quote:
모구아가 아니라 모과 겠죠. 아닌가요? 뭐 중요한 것은 아니고요.

모구아로 읽건 모과로 읽건 별 상관은 안하시는 모양입니다만, 방준영님이 모구아로 발음하시는걸 들었습니다. (아니..목우아였던가? :shock: )

Quote:

제 주장은 명확합니다. 편법으로 돌리기 위해 노력하는 것 보다 리눅스용을 개발할 것을 요구하는 것이 훨씬 좋다라고 생각합니다.
그래서 IE도 리눅스용을 만들어 달라고 요구 하는 것도 좋다고 생각합니다. 불여우 보다 성능과 기능만 좋다면 당연히 사용하겠습니다.

불현듯... 정치인들이 생각납니다. '아 국민들 절반 이상만 그분을 지지해주면 그분이 대통령이 될 수 있으니까, 경쟁상대인 그분만 포기하면 된다니까~'

MS은 안그래도 리눅스 안 퍼지게 막는데 혈안인데 리눅스 유저들이 MS에게 MSIE를 리눅스용으로 만들어 달라고 요구하면 호락호락 잘 만들어 줄거라고 생각하시는 사고방식은... 저나 제가 아는 다른 많은 F/OSS 유저들과는 좀 차원이 다르신 것 같다는 생각이 듭니다. 낙관주의라고 하기도 좀 어렵고... 뭐랄까... (아ㅤㅎㅐㅎㅤㅎㅐㅎ하다고 하면 좀 실례일 것 같고)

Quote:

기본 OS를 리눅스로 팔거나 OS가 없는 PC의 판매도 많이 생겨야죠.
지금도 있지 않나요? 이런 선택의 기회만 준다면 충분하다고 생각합니다.

리눅스를 기본OS로 파는 기업들도 벤처 붐때 꽤 생겨났지만 수익을 창출하는데 실패해서 거의 다 문 닫았습니다. OS없는 PC는 국내라면 용산에서도 많이 팔지만 시장 점유율은 5% 남짓한 것으로 압니다. (그리고 그 5%의 98%는 아마 윈도우를 불법복제본으로 쓸 겁니다)

선택의 기회 문제라고 보지 않습니다. F/OSS 진영의 속성상 개발자 인력 자원을 독재적인 권력으로 컨트롤이 가능한 강력한 마케팅적 황제를 가질 수 없다는 점이 확산의 장애로 남을 것입니다. (반대로 MS는 그런 황제의 존재가 최대 무기입니다.)

그리고 윈도 app을 돌릴 수 있는 linux또는 기타 OS들은 꼭 개발자만 원한다고 보지도 않습니다. 다른 쓰레드에서도 지적을 한 바가 있는데, 아마 마케팅 전략으로 게임정도만 커버가 가능한 윈도우 에뮬레이션 OS가 나와서, 윈도XP 홈 에디션의 반값에만 판매한다고 쳐도 국내 게임방(내지 PC방) 절반 이상 판매 가능할겁니다. 그정도면 최소 3-400만 카피는 됩니다.

물론 MS라는 최대의 경쟁자가 내놓는 장벽을 성공적으로 통과하거나 우회한다는 전제가 필요하긴 하지만 말입니다.

기본적으로 자본주의 사회의 산업은 시장논리로 움직이지, 희망사항으로 움직이지 않습니다. 만약 우리같은 호사가가 아닌 기업이 시장의 현실적 또는 잠재적 요구를 멋대로 해석하여 그에 따른 결정을 내린다면 현실에서 치명적 타격을 입을 것입니다.

you must know the power of dark side.

이한길의 이미지

이 글타래를 읽다보니 문득 오늘 DB시간에 들은 말이 생각나네요.
교수님이 DB종류의 역사를 설명하시면서...
현재 Object Oriented DBMS로 왔다..

셔 놓고선.. 왈.. 어떤 학생은 질문하기를...
"그런데 현재 가장 널리 퍼진 오라클은 RDBMS아닙니까?"

할꺼래요... 그래놓구선 누구 대답할 사람 있냐시더니...

RDBMS가 오랫동안 DBMS를 지배해와서...
갑자기 Object Oriented DBMS로 갈 수 없으니까..
Object-relation DBMS라는게 나왔고...
요즘 나온 오라클은 무늬만 RDBMS다구요..

그러시면서 이어서 이야기하시길...
MS역시 오랫동안 어플리케이션의 넓은 영역을 지배해와서..
갑자기 없어질 수 없고 무엇인가와 공존하다가 그쪽으로..
넘어가게 될 수밖에 없으며 오래 존재해온만큼 그 시간이..
오래걸릴 것이라고 하시더군요..

그리고 무엇인가가 나타났다가 실패하면 할 수록...
다른게 나타나면 공존하는 기간이 길어질꺼구요...

대략 맞는 이야기인것 같습니다.

이런 관점에서 보면 와인이나 모구아나...
참.. 훌륭한 프로젝트가 될 수 있는 것들이 아닌가 싶습니다

.............................
글 써놓구 페이지 넘어간줄은 모르고...
실수로 새글 썼나 싶어서 지웠다가 다시 썼습니다.. :oops:

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

jongwooh의 이미지

이한길 wrote:

RDBMS가 오랫동안 DBMS를 지배해와서...
갑자기 Object Oriented DBMS로 갈 수 없으니까..
Object-relation DBMS라는게 나왔고...
요즘 나온 오라클은 무늬만 RDBMS다구요..

그러시면서 이어서 이야기하시길...
MS역시 오랫동안 어플리케이션의 넓은 영역을 지배해와서..
갑자기 없어질 수 없고 무엇인가와 공존하다가 그쪽으로..
넘어가게 될 수밖에 없으며 오래 존재해온만큼 그 시간이..
오래걸릴 것이라고 하시더군요..

잠시 딴지를 걸자면...

데이터베이스 전공자로서 OODBMS를 연구해 본 결론을 잠시 인용하자면

1. OODMBS는 호스트 랭기지로 반드시 OOP를 써야 하며,
2. SQL에 해당하는 표준 질의 언어를 만드는 것이 거의 불가능할 정도로 난해하며
3. 기본적으로 class-instance와 다형성의 매핑이 그래프조차 아닌 네트워크 모델링에 최적화되어 있는 것이기 때문에 RDBMS보다 표현성이 더욱 제약을 받는 점

때문에 앞으로 시간이 한참 지나도 주류로 자리 잡을 수 없다고 DB관련 연구자들이 결론을 내린 상황입니다.

그래서 OODBMS 벤더들도 특수용도의 데이터베이스에 주로 사용되며 범용시장에는 진출할 생각을 하지 않습니다.

특히 OODDBMS를 쓸 때에는 질의의 결과를 돌려줄 인스턴스의 타입을 알 수 없는 상황이기 때문에 스몰토크 수준의 다이내믹 바인딩을 지원하는 OOP언어가 주류가 되지 않는 한 OODBMS는 오히려 RDBMS보다 불편합니다.

C++은 기본적으로 스태틱 바인딩이라서 OODBMS에 붙여도 인스턴스를 바로 변수에 로딩하지 못하고, C처럼 스트링 처리밖에 못합니다. 그것은 OODBMS가 내포한 가장 강력한 장점인 다양한 표현력을 포기해야 한다는 것을 뜻합니다.

또 OODBMS는 관계대수에 기반한 RDBMS와 달리 수학적 이론 위에 자리 잡은 데이터베이스가 아닙니다.

그리고 ORDBMS 경우에는 클래스를 레코드 타입으로 가질 수 있는 RDBMS이지 object 와 method (또는 operator) 위에 올라선 게 아닙니다. ORDBMS는 OODBMS와 RDBMS의 중간형이라기보다 RDBMS의 object 확장이라고 봐야 합니다. (기본 연산은 SQL 이며 instance의 비교부분만 oop를 사용합니다)

참고로 국제적으로 가장 권위있는 OODBMS의 권위자는 '김원' 박사님이고, 이분이 저술한 OODBMS 개념서가 현재 거의 전세계적으로OODBMS 강좌의 입문서로 활용됩니다. 이분도 90년대 초에OODBMS 관련 연구를 중지하고 UniSQL을 설립하셨었습니다.

you must know the power of dark side.

saxboy의 이미지

Quote:
참고로 국제적으로 가장 권위있는 OODBMS의 권위자는 '김원' 박사님이고, 이분이 저술한 OODBMS 개념서가 현재 거의 전세계적으로OODBMS 강좌의 입문서로 활용됩니다. 이분도 90년대 초에OODBMS 관련 연구를 중지하고 UniSQL을 설립하셨었습니다.

지금은 S모사에서 self-inspection을 설파하고 계시지요. :roll:

오만한 리눅서의 이미지

jwhan wrote:
특히 OODDBMS를 쓸 때에는 질의의 결과를 돌려줄 인스턴스의 타입을 알 수 없는 상황이기 때문에 스몰토크 수준의 다이내믹 바인딩을 지원하는 OOP언어가 주류가 되지 않는 한 OODBMS는 오히려 RDBMS보다 불편합니다.

WSDL하고 유사하군요...
왠지 java하고 궁합이 잘 맞을 것 같다는 생각이 드네요.

java도 부족한가?
WSDL에 따라 class가 자동 생성되기는 해도,
매번 동적으로 class가 만들어 지는 것은 아니니...

:evil: :lol:

tinywolf의 이미지

늘상 듣는 얘기라 그런지 스크롤의 압박으로 포기해 버렸습니다.. 털썩..

살살들 하세요..

ㅡ_ㅡ;

이한길의 이미지

jwhan wrote:
이한길 wrote:

RDBMS가 오랫동안 DBMS를 지배해와서...
갑자기 Object Oriented DBMS로 갈 수 없으니까..
Object-relation DBMS라는게 나왔고...
요즘 나온 오라클은 무늬만 RDBMS다구요..

그러시면서 이어서 이야기하시길...
MS역시 오랫동안 어플리케이션의 넓은 영역을 지배해와서..
갑자기 없어질 수 없고 무엇인가와 공존하다가 그쪽으로..
넘어가게 될 수밖에 없으며 오래 존재해온만큼 그 시간이..
오래걸릴 것이라고 하시더군요..

잠시 딴지를 걸자면...

데이터베이스 전공자로서 OODBMS를 연구해 본 결론을 잠시 인용하자면

1. OODMBS는 호스트 랭기지로 반드시 OOP를 써야 하며,
2. SQL에 해당하는 표준 질의 언어를 만드는 것이 거의 불가능할 정도로 난해하며
3. 기본적으로 class-instance와 다형성의 매핑이 그래프조차 아닌 네트워크 모델링에 최적화되어 있는 것이기 때문에 RDBMS보다 표현성이 더욱 제약을 받는 점

때문에 앞으로 시간이 한참 지나도 주류로 자리 잡을 수 없다고 DB관련 연구자들이 결론을 내린 상황입니다.

그래서 OODBMS 벤더들도 특수용도의 데이터베이스에 주로 사용되며 범용시장에는 진출할 생각을 하지 않습니다.

특히 OODDBMS를 쓸 때에는 질의의 결과를 돌려줄 인스턴스의 타입을 알 수 없는 상황이기 때문에 스몰토크 수준의 다이내믹 바인딩을 지원하는 OOP언어가 주류가 되지 않는 한 OODBMS는 오히려 RDBMS보다 불편합니다.

C++은 기본적으로 스태틱 바인딩이라서 OODBMS에 붙여도 인스턴스를 바로 변수에 로딩하지 못하고, C처럼 스트링 처리밖에 못합니다. 그것은 OODBMS가 내포한 가장 강력한 장점인 다양한 표현력을 포기해야 한다는 것을 뜻합니다.

또 OODBMS는 관계대수에 기반한 RDBMS와 달리 수학적 이론 위에 자리 잡은 데이터베이스가 아닙니다.

그리고 ORDBMS 경우에는 클래스를 레코드 타입으로 가질 수 있는 RDBMS이지 object 와 method (또는 operator) 위에 올라선 게 아닙니다. ORDBMS는 OODBMS와 RDBMS의 중간형이라기보다 RDBMS의 object 확장이라고 봐야 합니다. (기본 연산은 SQL 이며 instance의 비교부분만 oop를 사용합니다)

참고로 국제적으로 가장 권위있는 OODBMS의 권위자는 '김원' 박사님이고, 이분이 저술한 OODBMS 개념서가 현재 거의 전세계적으로OODBMS 강좌의 입문서로 활용됩니다. 이분도 90년대 초에OODBMS 관련 연구를 중지하고 UniSQL을 설립하셨었습니다.

그런가요?? 함 물어봐야겠습니다...
저는 주워들은 이야기라 뭐 뒷받침할 근거고 뭐고도 없는지라..

이야기 들려주셔서 감사합니다..

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

coyday의 이미지

Win32 포함, 에뮬 프로젝트가 성공적이지 못한 이유는..

에뮬이기 때문이죠 뭐.

북한산(X) 삼각산(O) 백운대(X) 백운봉(O)

jenix의 이미지

kenny007one wrote:

IBM은 왜 OS/2를 더더욱 발전시켜 Windows와 직접 경쟁을 하지 않고 아예 포기하고, OS 개발기술력은 세계최고라 볼수 있는 SUN사는 데스크톱시장에 진출안하고 그나마 애플은 이제서야 x86으로 선회하여 한번 경쟁할 기미를 보일까 하는 정도일까요?

kenny007one wrote:

그럼 얼마전까지 PowerPC를 쓴 애플 매킨토시와 x86 계열 프로세서의 IBM PC가 서로 실제 직접 경쟁하는 시장을 공유한다 말하나요? ( 이젠 x86을 써서 만약 카피 프로텍션이 풀리면 직접 경쟁하는 OS로 부상할수도 있습니다만 )

경쟁은 똑같은 조건하에 같은 기준을 갖고 서로 비교가능할때 직접 경쟁가능하다라고 하는겁니다.

kenny007one 님 말씀 참 이상합니다 -_-;
CPU 가 같아야 경쟁을 하는건가요?
아키텍쳐를 떠나 노리는 시장이 같으면 경쟁하는거겠지요.

애플은 이미 충분히 데스크탑 시장에서 경쟁하고 있었습니다.
한국시장이 특히 외소했을 뿐이지요.

x86 으로 선회하여 한번 경쟁할 기미를 보일까 하는 정도가 아니라
뒤집어 엎어보려는 전략이겠지요 --; ( 뒤집어 엎을 수 있을진 아무도 모르겠지만요. 적어도 한국시장에선 못 엎겠지요. )

MS Office 제품군, 버츄얼PC, 등등 Mac OS X 로 나오고, 수 많은 좋은 프로그램들이 Mac OS X 버젼이 나오는걸 보면 모르시겠습니까 -_-;;

p.s. 심지어 wwdc 2005 기조연설에선 ms office 쪽에서도 발표가 있었죠. 어차피 ms 는 소프트웨어를 파는 회사지 하드웨어를 파는 회사가 아니란거죠. mac os x 가 x86 이든 ppc 가 되었든 팔려서 office 수요로 필요로 한다면 ms 는 그걸 얼마든지 좋게 만들어서 팔겠다는 거죠.

---------------------------------------------------------------------------
http://jinhyung.org -- 방문해 보세요!! Jenix 의 블로그입니다! :D

다크슈테펜의 이미지

미국에서는 교육용 제품군 거의 대부분 아는 한 애플 제품이더군요...가본적은 없지만 교육용사진이나 아니면 지급제품 군을 보면 일반 피씨가 아닌 애플 제품군이었습니다.얼마전 어떤 학교의 교과서를 없애는 대신에 지급한다는 것이 아이북이더군요.한국은 예외입니다.전에 앨렉스 컴퓨터때보다는 가격 거품이 많이 빠졌지만 일본이나 미국에 비해서는 아직도 약간은 비싼편입니다.
그것때문에 꺼리는 것이지 양질의 소프트웨어는 위에서 말씀하신대로 나 맥용으로 나와있고 리눅스 보다는 좋은 편입니다.
PS:초등학교에서 교육 프리젠테이션 하는 것을 봤는데 아이무비로 수업하는 장면이었습니다.참 부럽더군요.

인생이란게 다 그런게 아니겠어요....? 뭘(?)
http://schutepen.egloos.com

이한길의 이미지

이한길 wrote:
그런가요?? 함 물어봐야겠습니다...
저는 주워들은 이야기라 뭐 뒷받침할 근거고 뭐고도 없는지라..

오늘 찾아가서 여쭤보니깐 교수님께서 맞는 말이라고 하시면서
이런저런 이야기를 해주시더라구요..

근데 제가 허접해서 거의 이해를 못했습니다.. ㅡㅡ;

하지만 한가지는 알아들은건 오라클의 최근 버젼에서는
ORDBMS가 모두 구현되어 있다는 거였습니다...

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

오만한 리눅서의 이미지

Mac이 Win32로 포팅됨으로 인해
Mac 어플용 에물은 기대해도 되는 것 아닐까염?

기반이 다 오픈소스니...

BSD에서는 Linux의 a.out이 에물되는 것으로 아는데...
이기회에 binary레벨에서는
Mac <-> BSD <-> Linux 통합되지 않을까...
기대를...

잘하면 M$ VS Linux,Mac,BSD 구도로
시장이 개편될 수도 있겠군염...

:evil: :lol:

정태영의 이미지

오만한 리눅서 wrote:
Mac이 Win32로 포팅됨으로 인해
Mac 어플용 에물은 기대해도 되는 것 아닐까염?

mac 은 win32 로 포팅되는게 아닙니다... x86 으로 포팅되는 것일 뿐이죠... mac 이 인텔진영으로 포팅된다고 달라지는건 없을 듯 하군요

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

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

warpdory의 이미지

kenny007one wrote:
대표적인 Windows 프로그램을 실행하기 위한 에뮬레이터(바이너리 호환도 포함) 프로젝트가 몇개 있습니다.

... 중략 ...

IBM은 왜 OS/2를 더더욱 발전시켜 Windows와 직접 경쟁을 하지 않고 아예 포기하고, OS 개발기술력은 세계최고라 볼수 있는 SUN사는 데스크톱시장에 진출안하고 그나마 애플은 이제서야 x86으로 선회하여 한번 경쟁할 기미를 보일까 하는 정도일까요?

좀 정확하게 하기 위해서 덧붙입니다.

OS/2 에서 돌아가는 윈도즈(공식적으로는 윈도즈 3.1 + win32s 1.25a 버전까지만 지원합니다만, 몇가지 해킹과 삽질을 하면 스타크래프트 정도는 잘 돌아갑니다.)를 돌리는 것은 에뮬레이터 또는 바이너리 호환이 아닙니다. 비슷하기는 하지만, 조금 다릅니다.
OS/2 안에서 하나의 방을 만들고 그 안에서 돌아가는 거라고 보시면 됩니다. - 정확히는 VDOS 라고 해서 가상 도스 환경을 만들고 그 위에서 돌아가는 겁니다. - VDOS 안에서 스타크래프트가 돌아가는 걸 보면 .... win32 환경이라는 게 뭘까.. 라는 의문이 들기도 하더군요. 그냥 요새는 IBM 의 VDOS 가 32 비트구나.. 라고 생각하고 있습니다.
wine 이나 wabi 등과는 꽤 다른 환경에서 돌아가는 겁니다.

IBM 은 몇가지 이유(독과점법 위반이라든가 등등의 이유, IBM 이 PC 용 OS 인 OS/2 까지 시장장악을 했다면, 1980년대 초반에 한번 겪었던 회사 분할의 악몽이 떠올랐을 겁니다. 메인프레임부터 중소형 서버를 거쳐 PC 까지 모두 IBM 이 장악하게 되는 시나리오였으니까요.)로 OS/2 를 강력하게 밀지 못했습니다. 물론, 현실적으로 또는 시장적으로는 실패했습니다만, 실제로는 IBM 기술진들이 대거 윈도즈 2000, 윈도즈 XP 개발에 투입되었기 때문에, 그나마 윈도즈가 이 정도라도 돌아간다고 보고 있습니다.

개인적으로는 ... 에뮬레이션 환경이라든가 하는 걸 별로 좋아하질 않습니다.
거기에 맞는 걸 쓰면 되는 겁니다.
물론, 요새 AMD 등에서 나오는 듀얼 코어 같은데서 쓰는 Xen 같은 건 조금 다른 얘기가 되겠고요.

IBM 이 OS/2 를 시장에서 포기한 것은(OS/2 개발은 여전히 이루어지고 있습니다. http://www.ecomstation.com 에 가 보시면 됩니다. 현재 64 비트 OS/2 의 베타버전이 나와 있습니다.) OS/2 를 개발해서 돈 버는 것보다, 윈도즈를 지원해서 돈 버는 게 더 많기 때문입니다. IBM .. 말 그대로 International Business Machines 입니다. 국제사무기기상사 .. 정도가 되겠지요. 돈 되는 거면 법망을 어떻게든 헤집어서라도 다 합니다.
물론, IBM 의 저 결정은 개인적으로는 조금 아쉽습니다만, 거의 15년 정도를 OS/2 가지고 잘 놀았고, 앞으로도 10년정도는 더 가지고 놀 수 있을 것 같아서 별로 아쉬울 것도 없습니다. 어차피 한국 IBM 의 OS/2 지원은 1997년 가을쯤부터 안 하고 있었거든요.


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

즐겁게 놀아보자.

익명 사용자의 이미지

모구아 알파는 언제쯤 사용해 볼수 있나요?

익명 사용자의 이미지

모구아가 모과로 익어 갈때쯤이면 볼 수 있지 않을 까요?

익명 사용자의 이미지

BSD 커널이 후져서 그런 겁니다. 리눅스 커널 0.99 버전 정도의 성능만 나와도 벌써 나왔을텐데,
방준영님의 실력이라면 충분히 나왔을텐데, BSD 커널이 후져서 방준영님의 애플리케이션 코딩 실력을 받쳐주지 못하기 때문에 못 나오고 있는 겁니다.

BSD 커널이 리눅스 커널 0.99 를 따라잡으려면 지금의 발전 속도로 볼 때 남북 통일 후, 국제 정세가 안정되고, 대한민국의 국민소득이 1인당 200 억 달러는 될 때가 되어야 하지 않을까 싶습니다.

http://kldp.org/node/56795#comment-232925