:: 게시판
:: 이전 게시판
|
- 자유 주제로 사용할 수 있는 게시판입니다.
- 토론 게시판의 용도를 겸합니다.
통합규정 1.3 이용안내 인용"Pgr은 '명문화된 삭제규정'이 반드시 필요하지 않은 분을 환영합니다.법 없이도 사는 사람, 남에게 상처를 주지 않으면서 같이 이야기 나눌 수 있는 분이면 좋겠습니다."
14/10/01 16:26
어제 집에 가서 클릭커히어로즈를 할라고 하는데 버전이 낮아서 안된다고 하던데 이거 때문이라고 하기엔 너무 유명한(!) 게임 같고...
그냥 크롬으로 하고 있는 중입니다.
14/10/01 16:36
부주의한 개발자라니... 억울합니다.
날고 긴다는 sun도 Date 와 Calendar 설계를 잘 못해서 그렇게 욕을 먹는데요. 그냥 호환성은 어려운겁니다. 미래를 예측하는 것도 힘들고요. 절대 개발자 탓이 아닙니다!! 크크크크 - 지나가던 뜨끔한 개발자.
14/10/01 16:38
이야 재밌게 읽었습니다. 윈도우 8.1이 6.3이라는 걸 오늘 유게에선가 보고 그런가보다 했는데 이런 이유가 있는 거였군요.
그런데 읽고 추천하려고 눌렀는데 왜 추천이 안 될까요 ㅜㅜ
14/10/01 16:49
네. 윈도 비스타가 6.0이었는데, 함부로 메이저 버전을 올렸다가 무슨 호환성 문제가 발생할지 모르니 버전 번호를 올리는 데 소극적이 되는 것이죠. 그래서 윈도 7, 윈도 8, 윈도 8.1을 거치면서 마이너 버전만 1씩 쪼잔하게 올렸습니다.
심지어 윈도 8.1은 기묘한 기술을 도입했는데, 앱 개발자가 윈도 8.1에 맞춰 개발했다고 명시적으로 앱 내부에 적어두지 않는 이상(이를 '매니페스트'라고 합니다), 앱에 제공되는 윈도 버전은 '윈도 8.1'이 아니라 무조건 '윈도 8'이 됩니다. 즉, 앞으로 윈도 10이 나오든 윈도 11이 나오든, 예전에 개발된 소프트웨어들은 자기가 윈도 8에서 실행되는 줄 알게 된다는 것입니다. 호환성을 위해서죠. 이쯤 되면 사실상 버전 번호가 의미가 없어진 상태라고 볼 수 있죠.
14/10/01 17:01
호환성 문제 때문은 아니었을겁니다. 그랬다면 비스타도 5.2로 할당되었겠죠.(XP 다음 버전이니)
MS 내부에서 윈도우는 커널이 대대적으로 바뀌지 않는 한 메이저 버전을 바꾸지 않는 걸을 기조로 삼고 있고, 그 일관성에 맞추어 버전을 할당하고 있습니다. 자세한 내용은 아래 리플로 달았습니다.
14/10/01 16:55
윈도우즈 버전은 그냥 내부 일관성 때문으로 알고 있습니다. Windows 2000은 NT 4.0 다음에 만들어진 아이이고, 2000년을 기념하기 위해 네이밍만 바꿨을 뿐, 내부버전은 순서대로 나갔기 때문에 NT 5.0이라는 버전이 할당되었습니다. NT라는 이름이 버려지긴 했지만, NT 커널이 Windows Server를 위한 커널이었고, NT 4.0이 Windows 3.1 Network Edition에서 발전된 버전이라는 점에서, 이 버전할당은 일견 일관성 있다고 볼 수 있습니다.
헌데, Windows 2000(NT 5.0)까지는, 윈도우는 서버용 NT 커널과 클라이언트용 윈도우 커널이 분리되어 있었습니다. 하지만 윈도우 커널이 너무 지저분했기 때문에, 마지막인 Windows Me 이후 NT커널을 이용하여 서버/클라이언트 버전을 모두 만들기로 결정합니다. 이후 NT 5.0 커널을 내부적으로 약간 개선하고 클라이언트 호환성을 추가한 NT 5.1로 Windows XP를 만들고, 이를 추가적으로 개선하여 NT 5.2로 Windows 2003을 발표합니다. 이 성공을 바탕으로, MS는 윈도우 커널을 완전히 정리하여, 제대로 한번 만들어 보겠다는 야심찬 계획을 품습니다. 하지만 이때 웜 바이러스 관련 대란이 터지고, 이거 수습하는데 시간이 너무 오래걸리는 바람에 새로운 커널은 제대로 마무리 되지 못한채 시장에 나옵니다. 이게 비운의 커널인 NT 6.0(Window Vista, Windows Server 2008)입니다. 비스타의 실패 이후, NT 6.0 커널을 좀 발전시켜, 최초에 만들고 싶었던 제대로 된 커널을 만들어 시장에 내놓는데 사실상 이 버전이 NT 7.0 되지 않을까 생각했지만 MS는 6.0에서 그렇게 많은 변화가 생겨났다고 생각하지는 않았는지 이게 NT 6.1(Windows 7, Windows Server 2008 R2)이 되었습니다. 해당 커널은 조금 더 개선되어 NT 6.2라는 버전이 할당되고, Windows 8, Windows Server 2012가 됩니다. 이후 Windows 8.1과 Windows Server 2012 R2는 NT 6.3을 할당받게 되었구요. 역사를 보면, 윈도우가 내부적으로 NT 버전명을 유지해 가는 건 별로 문제가 없어보입니다. 대외적으로 크게 홍보해야 하므로 대외 버전은 Window 7이나 8 같이 그때 그때 마케팅 정책에 맞게 바뀌지만, 내부 버전은 큰 변화가 있었을 때 Major Version을 Update하고, 작은 변화가 있었을 때 Minor Version을 Update하며, 내부 버전은 마케팅용 네이밍과 별개로 간다. 가 MS 내부 정책입니다. 이는 Visual Studio 2012의 내부버전이 VS 11라던가 하는 걸로 확인 할 수 있고, 개발 버전 번호를 어떻게 할당할 것인가는 각 개발팀에 일임한 것으로 보입니다. (Visual Studio가 Major Version만으로 Update하는 것에 비해 IE팀이나 하는 OS 팀은 Minor 버전까지 써가면서 차등을 두는 등, 뭐 이건 Unix쪽과 약간 닿아있기도 한 OS팀의 자존심 같은 것으로 보이기도 하지만요. )
14/10/01 17:04
오, 생각해 보니 버전 번호로 major.minor 를 쓰는 것 자체가 MS 제품 중에서 상당히 특이한 일이군요. (물론 내부 버전만 그렇긴 합니다만) 비주얼 스튜디오도 그렇고 오피스도 그렇고 IE도 요즘은 다 메이저만 쓰는군요. 재밌네요.
제가 커널에 대해 잘 모르지만, 소문을 듣자 하니 윈도 8.1도 커널쪽에서 상당한 부분이 바뀌었다고 합니다. 그런데도 메이저 버전을 올리지 않는 걸 보니 버전 올리는 데 소극적이 된 게 아닌가 하는 생각이 든 것이죠. 어차피 마이너 버전만 바뀌면 구별하는 건 문제가 없으니까요. (어찌 보면 다른 제품이랑 비슷하게 되는 거죠. IE가 major.minor 쓰다가 지금은 숫자 하나로만 관리하듯...) 게다가 매니페스트까지 도입했고... 그래서 개인적으로 궁금한 게 윈도 10의 버전 번호를 과연 몇일까 하는 점입니다. 여기서도 6.4를 쓴다면 MS가 진짜로 버전 올리는 데 소극적인 거겠죠.
14/10/01 17:21
5.0에서 6.0으로의 변화는 정말 대대적이긴 했습니다. 바뀐 것만으로 따지자면 사실 6.1 -> 6.2(그니까 제 기준으로는 2008 R2 -> 2012)도 RIO의 도입이라던가, 메모리 할당 알고리즘의 변경 등 상당한 변화가 있었습니다만, 5.0에서 6.0에서의 변화만큼 크지는 않았으니까요. (Windows Vista 부터 지원하는 API들이 생겨나고, UAC인지 뭐시깽인지가 등장하고, 덕분에 Security 관련한 개념이 싸그리 몽창 뒤바뀌고....)
뭔가 개념을 뒤엎는 수준의 기능 추가가 생기지 않고서는, 당분간은 계속 마이너 버전만 업데이트 할 것으로 보입니다. 사실 내부 버전 체크 함수는 삼백년 전부터 0x0501 >= _WIN32_WINNT 같이 비교하도록 권장하고 있어서 버전 때문에 호환성 문제가 생길 것 같지는 않구요. 물론 그 모든 것과 별개로, NT 버전이 3.1부터 시작한 것은 호환성 문제가 맞긴 하지만 말이죠. :P
14/10/01 17:30
네. NT 3.1이야 말로 호환성을 위해 버전을 건너 뛴 아이죠. NT 커널은 사실상 윈도우랑 전혀 상관 없이 시작한 프로젝트임에도 불구하고, 윈도우와의 호환성을 위해 NT 3.1부터 시작했으니까요.
14/10/01 17:22
아마 6.4일겁니다. 7.0이 될려면 커널을 대대적으로 갈아엎어야 하는데 (XP -> Vista 의 변화처럼) 윈도우 10에서도 그러한 변화는 안 보이니까요.
14/10/01 17:18
http2는 참 묘하더라구요.
개발자나 사용자 입장에서는 그닥 달라지는 게 없겠지만, 브라우저 web / was 서버 개발 및 네트워크 장비 단에서는 대격변이 몰아칠 듯합니다.
14/10/01 17:26
13년동안 윈도우 서버만 다루다가 지금 리눅스 서버 작업을 해야 할 일이 생겨서 잠시 현실 도피 겸 정리 좀 해봤습니다. 흐흐
14/10/01 17:31
저는 전형적인 리눅스 꼰대인데, 예전에 IOCP가 생각보다 무척 위대한 기술인 것을 깨닫고 왜 이런 게 리눅스에는 없는지 안타까웠던 기억이 있습니다.
제 아무리 epoll이라도 기본적으로는 폴링인데, 그보다는 IOCP가 훨씬 엘레강스한 것 같아요. 빌 게이츠 형님이 최고시다...
14/10/01 17:38
안그래요.;;; RIO 관련문서 보시면 아시겠지만, 일단 개념상으로는 IOCP가 되게 엘레강스 해보이는데, 얘가 문제가 좀 있습니다. IOCP가 아시다시피 버퍼를 물고 들어갔다가 IO가 끝났을 때 GQCS에서 튀어나오는 아이인데, 저 물고들어가는 버퍼가 page out되면 안되니까 버퍼에 락을 겁니다. 그리고 튀어나올때 락을 풉니다. 매번 들어가고 나올때 마다요.;;;; 덕분에 IOCP로 서버 짜서 vtune같은거 돌려보면 CPU 대부분이 버퍼 락 비용으로 들어가요. 그래서 MS가 모든 걸 버리고 RIO를 추가했고, 직접 테스트 해 본 결과 IOCP 대비 CPU 비용이 1/3로 줄어드는 기적을 보았습니다. 폴링이 최고시다.....
14/10/01 17:48
헉 크크 페이지 록을 거는군요. 하긴 페이지 아웃되면 곤란하니까 어쩔 수 없는 선택이었겠네요.
RIO는 아직 살펴보지도 못했지만, 그게 그렇게 좋다니 놀랍네요. 제가 편향된 벤치마크를 본 것일 수도 있지만, 트윅 안 한 epoll은 IOCP보다도 약간 성능이 안 좋던데... RIO랑 비교하면 과연...
14/10/01 17:52
그냥 거의 커널 API를 오픈한 수준이예요. Multi Thread 지원도 안해서 손으로 한땀한땀 lock까지 걸어줘야 하는(내가 무슨 이태리 장인도 아닌데!!)...
근데 그만큼 쥐어 짜낼 수 있어서 확실히 성능은 잘 나와요.
|