'Snow Leopard'에 해당되는 글 5건

  1. 2009.09.03 [눈범 진실 3] GCD: Grand Central Dispatch 1부
  2. 2009.09.03 [눈범 진실 2] "64비트 Or 32비트 !"
  3. 2009.09.03 [눈범 진실] "눈범이가 서비스팩이라고라!!"
  4. 2009.08.27 SnowOSX Universal 10.6 GM (10a432) v3.5
  5. 2009.03.28 WWDC의 개최일이 공개되었습니다. (2)

[눈범 진실 3] GCD: Grand Central Dispatch 1부





계속되는 arstechnica.com의 눈범이 리뷰입니다. 가면 갈수록 제 한계를 넘어가는 전문적인 내용입니다...ㅋ! 하지만 이 부분을 빼고 스노우를 논할 수 없는 거 같습니다. 한계내에서 가급적 저 같은 유저들이 취할 수 있는 정보 중심으로 옮겨 봤습니다...특히 스노우 GCD 의 밑그림을 제공하는 프로그램 랭귀지 부분 (Blocks)에서는 도저히 제 머리가 못쫓아가서 거의 겉만 핥았습니다...이해해주시길...^^  혹시 삐돌이님이 이 글을 보신다면 잘못된 부분 및 빠진 부분을 지적해 주실수도 있을거 같습니다만 ...^^

위 그림이 생각나시나요? 익숙한 그림이죠...맥 사용자는 다 아실듯한...이전 흑백화면의 매킨토시 때부터 부팅때말고 프로그램 실행시 돌아가는 바람개비입니다. 지금은 무지개 빛으로 변했죠. 헌데 이게 멋진게 아니더군여. 특히 멀티태스킹 작업환경에서 프로그램 실행시 여러분의 맥컴퓨터가 버벅되는것을 표현하는 것입니다. CPU는 갈길 먼데 또 새로운 일하라고 명령하면 "지둘려~"하면서 심심한데 무지개 바람개비나 보라는...ㅋㅋ

근데 맥에서 GCD가 사용되는 프로그램환경에 이르면 예쁜 무지개도 더이상 나타날 필요가 없다는 군여...!!

--------------------------------------------------
http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/8

다다익선?

잠깐 무어의 법칙을 들춰보자. 오늘날 약간의 오해가 있긴 하지만 그가 65년 처음 말한 것은 "컴퓨터 스피드가 매년 두배로 빨라질 것"이었다. 이후 무어는 자신의 주장을 "2년"이라고 수정했었다. 컴퓨터 시대가 열리고 그의 법칙이 맞아 떨어진 기간이 있었지만 오늘날 문제는 그게 아니다. 

이슈를 재조명하자면 "스피드가 두배로 빨라지는게 아니라 실리콘 칩의 트랜지스터 집적도(density)가 2배로 커지는 것"이다. 컴퓨터 클럭 스피드가 한계점에 도달한 지금 인텔, AMD같은 칩제조사들은 개발 포커스를 스피드에서 트렌지스터 집적 분야로 옮겨갔다. 클럭스피드는 오히려 거꾸로 가는 모양새다. 맥프로의 경우 2009년 최상위 모델이 2.93GHz인데 반해 2008년 최상위 모델은 3.2GHz다. 코어수가 다를 뿐이다. 하드웨어의 끊임없는 발전과 마케팅을 위한 어쩔수없는 방편이지만 증가일로의 다중코어 칩을 위해 프로그래밍 코드를 쓰는 프로그래머들은 사실 난관에 봉착했다. 

일반적으로 보자면 듀얼 코어 CPU가 싱글 코어에 비해 사용자 어플리케이션 작동시 2배로 빨라지는게 아니다. 그렇게되기 위해선 프로그램이 듀얼 코어를 이용하도록 만들어져야한다. 현재의 모양새는 프로그래머들이 다중코어 최적화를 위한 준비를 못하고 있는  가운데 하드웨어 회사는 모든 책임을 프로그래머에게만 던져놓은 그런 양상이다.

개발자를 위한 운영체제

눈범이가 이런 환경속에서 태어났다는 것을 기억하시라!  지금까지 컴퓨터 운영체제 제조사의 중요한 책임중 하나가 "보안"이었다면 2009년 오늘부터 더 중요해지는 책임은 날로 증가하는 칩셋 자원을 보다 효율적으로 이용할 수 있는 방법을 프로그래머와 써드 파티 어플 제조사에게 제시하는 것이다. 그리고 이번 눈범이에서 가장 눈에 띠는 대목이 개발자들에게 오늘날의 멀티코어 실리콘 칩셋을 보다 효율적으로 그리고 이미 만들어져있는 "다다익선"의 구조를 활용하는 방법을 제시하고 있다는 것이다.

이제 눈범이에 포함된 두가지 특별한 API (어플리케이션 프로토콜 인터페이스인가요?!)에 대해 논하고자 한다. 그 첫째가 Compiler다.

LLVM & Clang
(역자주: 이제부터 모르는게 마구 나옵니다.ㅋㅋ Low Level Virtual Machine(LLVM)이란 하나의 컴파일러 하부구조를 의미한다.  C++로 만들어졌으며 프로그램 최적화를위한 compile-time, link-time, run-time 그리고 idle-time을 위해 만들어진 것이다. by Wikipedia]

애플은 오래전부터 오픈소스 프로젝트인 LLVM에 전략적 투자를 해왔다. 이미 레퍼드에도 도입된 것이며 LLVM 역할은 OpenGL 기능과 연관되는 JIT방식의 소프트웨어 효율성을 극대화 시켜주는 것이다. 하지만 레퍼드에서의 사용은 미미한 것이었다. 오래전부터 언급한 것이지만 이런 미미한 사용일지라도 애플의 원대한 플랜을 볼 수 있는 대목이었다. 프로그래밍의 스피드 향상과 버그발생을 낮춰주는 LLVM. 지금까지 사용해온 GCC를 LLVM로 완전히 대체한다는 것이 꿈이기만 한 일일까? 

GCC를 버리지만 GCC와 호환되는 완전한 LLVM 기반의 컴파일러 시스템을 우리는 Clang 프로젝트라고 부른다. 그리고 눈범이의 출시는 바로 Clang과 LLVM이 애플의 "컴파일러 전략"임을 공식 선언한 것이다!!!   

Clang(guage)은 현재 C, Objctive-C, 그리고 약간의 C++ 을 지원한다. 하지만 장점은 컴파일 타임이 짧고 더 빠른 실행 속도다. GCC 4.2와 비교해서 Clang은 3배나 빠른 속도를 가져오며 프로그래밍의 단순화가 가능하다. 현재로서 스노우는 LLVM을 백엔드로해서 프론트엔드에 Clang과 GCC 4.2의 혼합형 컴파일러를 사용중이지만 이 조차 5-25%의 스피드 향상을 가져왔다. 게다가 애플은 iCal, Address Book, Xcode, 그리고 Ardium, Growl 등의 써드파티 소프트웨어 프로그래밍에 Clang을 도입했다. 더 중요하게는 Clang에서 아직 호환되지 않는 C++을 스노우가 지속되는한 반드시 호환되게 만들겠다는 애플의 약속이다. 

업계 리더

Clang/LLVM 도입은 애플로 하여금 마침내 개발 플랫폼의 완전한 주도권을 쥐게되는 것이다. 그동안 써드파티 개발자에 목메달아온 환경을 완전히 뒤바꿀수있는 기회가 온 것이며 이는 애플의 역사가 보여주는 과거의 점철된 실패에서 배운 결과물이다. 많은 시간이 걸렸지만 이제 스노우의 Xcode가 진정으로 인정받게 된 것이다. 자 그럼 이제부터 이러한 프로그래밍 하부구조의 변화가 멀티코어 칩셋구조를 이용하는 것과 어떤 관계가 있는 것인지를 찾아보자. 

스노우가 제시하는 2번째 API: Blocks

애플이 눈범이를 통해 소개한 Blocks는 일종의 C 랭귀지의 확장이다. C랭귀지와 이의 변종인 C++,  Objective-C,  Objective-C++ 등을 지원하는 하나의 묶음 틀(closures)이다. 

이미 존재해온 것이긴 하고 또 비전문가들에겐 먹힐리가 없는 소리가 되겠지만 그래두 blocks의 의미가 스노우에서 차지하는 비중을 설명하고자한다. 가장 쉽게 말하자면 blocks는 데이터 형태의 또다른 컴파일 기능이다. C 랭귀지 변종들도 이런 데이터 형태로 움직인다. 이런 언어체계는 컴파일 타임에서 만들어진 기능들을 패스(전달경로?)하는 것이다. 이런 기능들을 조정하는 것은 별도의 Argument를 패스해주면서 발생한다. 이런 관계가 엄청난 시간소모적 작업으로 나타난다. 

Argument를 패스하는 것이 거추장스럽고 통제하기 어려운 작업인것은 프로그래머들이 익히 알고 있는 사실이다. Block 은 덩어리의 명령체계로 이런 복잡한 작업을 우회에서 기능구현을 실현하는 것이다. 그리고 이런 실행은 CPU 쓰레드 작업에 안정성을 확보한다. 이로인해 갑자기 C  랭귀지가 보다 다이나믹해졌다는 것을 알수 있다. 더 고차원의 프로그램에 이용될 수 있다는 것이다. 

애플이 스노우를 통해 구현한게 약 100가지가 넘는 Blocks 형태의 새로운 API다. 이는 명령어 처리 계통에서 획기적인 발판이 되는 것이다. 애플의 의도는 이런 blocks들을 C 기반의 랭귀지에 공식 확장자로 이용하려는 것이다.

Concurrency: 그 시조

오래전부터 다수의 독립적인 컴퓨팅 디바이스들을 효율적으로 사용한다는것은 너무나 어려운 일이었다. 수십년 넘게 슈퍼컴퓨터 하드웨어 소프트웨어 개발자들이 도전해왔고 이제는 그 도전의 범위가 데스크톱, 모빌컴퓨터까지 확대되고 있다. 

PC업계에서 보면 누구보다 빨리 이런 도전을 성사시킨 회사가 있다. 20년전에 창립된 Be, Inc.다. Be 는 당시 컴퓨팅 환경의 제약을 떨쳐버리는 획기적인 PC 플랫폼을 만들어보자는 목표로 태어난 회사였다. 여러 독립적인 하드웨어를 하나로 묶어서 활용해보자는 당찬 시도였다. Be는 듀얼 CPU 데스크톱 컴퓨터에 전혀 새로운 BeOS가 탑재된 시스템 BeBox를 결과물로 선뵀다.   

당시 "Pervasive MultiThreading"(멀티스레딩의 전파)는 Be가 내건 캐치프레이즈였다. BeBox와 BeOS가 탑재된 컴퓨터 시스템은 하드웨어가 지원하는 모든 자원을 국물하나 남기지 않고 쥐어짜내 사용하는 것이었다. 업계는 경이의 시선을 멈출수없었다. 66 mhz CPU 2개를 꼽아넣은 시스템에서 멀티 오디오 씨디 트랙이 재생되는 가운데 다수의 비디오 파일을 동시에 재생시키고 있었고 그럼에도 불구하고  User Interface는 안정적으로 굼뜨지 않게 반응하고 있었다.

BeOS의 광팬들이 생겨났고 그들은 아직도 오늘날 컴퓨터 보다 훨씬 더 부드러웠다고 말한다. 왜 그런 말을 하는지 충분히 공감하고도 남는다. 그 정도로 충격적이고 혁명적인 기술이었다. 

90년대 Be가 설자리는 좁았다. 또 마소의 독과점식 몰아치기 경쟁을 피해갈수도 없었다. 애플은 거의 Be를 인수할뻔했다. 하지만 마지막에 스티브 잡스의 NeXT를 인수하고 말았다. 나머진 모두가 아는 역사다. 짚고 넘어가려는 대목은 바로 이것이다. BeOS의 멀티쓰레딩은 정말 사용자의 입장에서 너무나 환상적인 것이었지만 당시 프로그래머들에겐 나이트메어와 다름없었다. 그게 실패의 이유였다. BeOS는 모든것이 쓰레드와 관련됐고 이런 구조가 당시 프로그래머들에게 맞아떨어질 수가 없었던 것이다.

병렬(Parallel) 프로그래밍은 악명높다. 전세계 최고의 프로그래머라해도 로우 레벨 랭귀지 C 또는 C++ 을 갖고 덩치 크면서 동시에 작동하는 멀티쓰레드 프로그램을 만들라한다면 골목골목 장애물을 만나게 되고 헤어나올수없는 늪에 빠지게 된다. 결과물은 버그투성이가 되버린다는 것도 빼놓을 수 없는 포인트다. 컴퓨터 프로그래머들이 말하는  Heisenbug가 바로 이를 두고 하는 말이나 다를 바 없다.

BeOS 가 등장하고 19년이 흘렀다. 하지만 여전히 멀티쓰레드 프로그래밍은 찾아보기 힘들다. 하드웨어는 저만치 앞서있는데 이를 받쳐줄 프로그래밍이 여전히 뒤쳐져 있는 것이다. 옥타코어 맥 프로 조차 싱글 쓰레드 명령을 수행할때 한개의 코어만 100% 쓰고 나머지 15 코어가 놀고있는 것을 볼수있다. 

그리하여 눈범이가 나온것이다. 


---------------------------------------------------------------------------------------------------------------------------


출처 : x86osx.com jp님의 글

http://x86osx.com/bbs/view.php?id=freeboard&page=1&sn1=on&divpage=4&sn=on&ss=off&sc=off&keyword=jp&select_arrange=reg_update&desc=desc&no=19845
Trackback 0 Comment 0

[눈범 진실 2] "64비트 Or 32비트 !"




눈범이 출시이후 가장 논란의 대상이 되는 것이 바로 "64비트" 관련입니다. 특히 마빠/윈빠들의 공격이 치열합니다. 굳이 예를 들지 않아도 "진정한 64비트가 아니다" 라는 말들이 나오고 있습니다. [한국서 그런 논쟁이 벌어졌다는 것은 아닙니다. 미국 PC World, Wall Street Journal 등 다수의 IT 기자/전문가들이 하는 말입니다. 

관련해서 ArsTechnica.com 라는 온라인 IT 매체의 존 서라큐자라는 기자는 장장 24페이지에 달하는 "스노우 리뷰"를 썼습니다. 미친맥에서 조차 "Ars Technica의 설범 리뷰가 나오기전에는 진정한 리뷰는 없다"라고 할 정도 였으니까요. 저두 왜라고 생각했지만 오늘(미국시간 1일) 그 리뷰를 보고 알았습니다. 너무나 긴 내용이고 전문적인 내용이라 머리에 쥐나도록 훑어봤습니다...ㅋㅋ 하지만 64비트 관련해서는 한번 쯤 짚고 넘어가도 될 듯 싶습니다. 울 사이트 고수님들이야 당연히 아시는 거겠지만 저처럼 문외한 들은 이제서야 "아...스노우가 추구하는 64비트가 이런 의미이구나"하고 깨달았으니까요...^^

http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/5
http://www.osnews.com/permalink?379368

------------------------------------------

애플은 지난 2003년  팬저를 출시하면서부터 "64비트 운영체제로의 구현"을 시도해왔다. 당시엔 단지 파워피시 기반의 최신 기종 G5 CPU를 위한 최소한의 64비트 지원이었을 뿐이었다. 2005년엔 타이거를 통해 GUI 라이브러리를 건들지 않는 한도내에서 진정한 64비트 지원 체제를 제시했고 2007년엔 마침내 레퍼드가 64비트 GUI 어플리케이션 지원을 가능케했다. 하지만 레퍼드의 64비트 지원은 코코아 어플리케이션에만 국한된 것이었고 사실상의 카본 지원을 포기한 것이나 다름없었다. 따라서 레퍼드의 64비트 지원은 상당히 놀라운 것이었지만 실질적인 맥 OS X가 64비트 완전 지원의 경지에 도달하기에 모자란것이 사실이었다. 그래픽 차트를 보면 그 진행과정을 눈으로 볼 수 있다.

K64
     
스노우 레퍼드는 실질적으로 64비트 커널을 포함시켜 32비트와 64비트 어플들을 동시에 지원하는 첫 Mac OS X다. 물론 모든 맥 컴퓨터에서 디폴트로 64비트 커널(애플은 이것을 K64 라고 부른다)이 작동하는 것은 아니다. 그 이유는 간단하다.  커널에 의해 로딩되는 다양한 plug-ins들이 바로 디바이스 드라이버다. (우리는 이것을 그 유명한 kext; kernel extension이라고 하죠..ㅋ) 눈법이가 64비트 커널로 작동한다면 디바이스 드라이버들도 64비트로 만들어진것만 로딩된다. 눈범이가 최초의 64비트 커널을 포함한 Mac OS X라는 점을 감안할때 눈범이 릴리즈 쳣날부터 64비트 체제로 그리고 모든 디바이스 드라이버가 준비된 상태로 맥을 사용할 커스토머는 손가락 꼽기라는게 자명한 사실이다.

하지만 애플은 디폴트로 64비트 커널이 작동하는 모델을 2008년 이후 생산된 "Xserver"로 한정지었다. 의미인 즉, Xserver에 장착된 디바이스 드라이버들은 이미 64 비트 지원 가능하도록 준비됐었고 이제 눈범이를 통해 그 기능을 이용할 수 있다. 

64비트를 지원하는 CPU (코어2듀어/제온 이상)가 장착된 맥모델 중에서도 64비트 커널로 작동하지 않는 것들이 있다는게 좀 실망스럽다. 하지만 스노우가 업데이트되면 이런 문제는 사라질 것이다. 다음 테이블이 맥에서 64비트 커널 지원여부를 설명한다.      

Product                               Model name                 K64
Early 2008 Mac Pro              MacPro3,1                  Capable
Early 2008 Xserve                Xserve2,1                   Default
MacBook Pro 15"/17"         MacBookPro4,1             Capable
iMac                                      iMac8,1                   Capable
UniBody MacBook Pro 15"  MacBookPro5,1             Capable
UniBody MacBook Pro 17"  MacBookPro5,2             Capable
Mac Pro                               MacPro4,1                 Capable
iMac                                      iMac9,1                   Capable
Early 2009 Xserve                Xserve3,1                   Default


64비트 커널 작동이 가능한 맥 모델들이 디폴트로 32비트 커널로 작동하게 돼있지만 부팅할때 "6"과 "4"를 동시에 누르면 64비트 커널이 작동하는 것을 알수 있다. 아예 첨부터 64비트로 작동하게 만들고 싶다면 command를 이용해 "arch=x86_64를 "  boot.plist 에 수정, 입력시켜주면 된다. 만약 32비트 커널로 다시 바꾸고 싶다면 시동시 "3"과 "2"를 동시에 누르면 된다.  

한편 위 차트에 빠져있는 일부 맥노트북(맥북/맥에어 등)은 64비트 CPU와 64비트 EFI까지 준비된 기종이지만 의도적으로 32비트 커널로만 작동하도록 돼있다. 이로 인해 애플에 대한 원성도 있지만 조만간 해결될 것으로 보인다. 

왜 64비트 커널이 디폴트로 작동하지 않는 이유에 대해서는 이미 드라이버 지원 문제를 언급했다. 하지만 스노우가 나왔고 드라이버 지원이 서서히 해결되면 당연히 64비트 커널로 사용해야된다고 생각하는 사람들을 위해 추가적인 설명을 보태겠다. 우선 RAM 메모리와의 관련성이다.  레퍼드 32비트 운영체제임에도 불구하고 32체제의 상한선으로 알려진 4GB 이상의 RAM을 활용할 수 있다는것을 모두 알것이다. 하지만 RAM 사이즈가 증가하게되면 어플리케이션이 아니라 커널에서 작동하는 address space depletion 문제가 발생할 수 있다.(잘 이해가 안됩니다...ㅋ)

32비트 커널은 사실 32비트 어드레스 스페이스(4GB RAM)만을 사용하는 것이다.  이 것이 문제는 아니다. 커널이 4GB이상의 메모리를 요구하진 않기 때문이다. 하지만 커널의 일부 역할 중에는 시스템 메모리를 조절하고 운영해주는 기능이 있다. 그리고 그 커널은 64 byte 구조를 이용해 RAM의 각  4 KB 페이지를 읽고 조정한다. Kilobytes가 아니라 64 byte 구조임을 잊지 마시라. 

하지만 머지않은 미래에 맥은 96GB RAM을 사용하게 된다. 지금으로써는 상상하기 어렵지만 사실 5년전 지금과 같은 맥의 8 GB RAM도 상상하기 어려웠다. 96GB의 램을 트래킹하고 조정하려면 1.5GB의 커널 어드레스 스페이스가 요구된다. 따라서 현재로서 4GB 기준의 램 메모리를 감안할때 스노우 레퍼드의 64비트 커널을 사용해서 3분의1에 해당하는 메모리를 잠식한다는 것을 감안해야한다.   

한편 64 bit 커널은 무한대로 kernel address space를 사용할 수 있다.(16 exabytes) 그리고 데스크톱 시장에서의 RAM메모리가 빠르게 확장되는 가운데 64비트 커널은 필연적인 것이다. 지금 당장은 아니더라도 조만간 64비트의 상용화가 도래할 것이다. 또 서버의 경우는 이미 두자리 숫자의 RAM이 사용되고있다. 

맥의 64비트가 가져오는 장점 중 또다른 한가지는 스피드다. 애플이 주장하는 것을 보면 call entry point에서 250% 더 빠르고 kernel user/kernel memory copy에서 70%가 더 빠르다고 한다.

벤치마크가 이를 입증할 것으로 보인다. 하지만 일상적인 사용자들은 64커널 때문에 성능향상을 느낀다는것이 불가능하다. 다만, 64비트 커널이 서버단에서의 병목현상을 없애는데 큰 기여를 할 것은 이론의 여지가 없다.

따라서 64비트 운영체제하에서 64비트 커널이 제대로 작동하는 것을 느낄 수 있다는 것은 결국 96GB RAM을 장착하고 32비트 디바이스 드라이버 하나도 없는 시스템에서만 가능한 것이다.  이제 왜 애플이 완전한 64비트 운영체제를 선보이면서 일부모델에 32비트 커널 모드로 작동하게 했는지를 알것이다. 애플의 시작으로 조만간 모든 사람들이 64비트 컴퓨팅시대를 맞게될 것은 분명하다.

마지막으로 아주 주요한 포인트가 있다. 스노우 레퍼드에서 64비트 어플리케이션을 구동시키고 4GB RAM 이상의 메모리를 설치한다는게 반드시 64비트 커널을 요구하는 것은 아니다. 이미 스노우 레퍼드는 32비트 커널 모드에서도 64비트 어플리케이션과  4GB 이상의 RAM 설치를 완벽하게 지원한다. 

64비트 어플리케이션

스노우는 현재 아이튠/Grapher/디비디플레이어만 제외하고는 모든 따라오는 어플이 64비트이다. Finder, Dock, Mail, TextEdit, Safari, iChat, Address Book, Dashboard, Hekp Viewer, Installer, Terminal, calculator 등 모든것이 64 bit 프로그램이다. 애플은 또 앞으로 가급적 32비트 API 지원을 줄여나간다고 했다. 말인 즉, 64비트 소프트웨어의 강력한 추진이다. 이미 레퍼드 시절 소개된 Objective-C 2.1 런타임도 64 bit만 지원하고 있다.  가장 눈범이에서 가장 중요하게 나타나고 있는 64 bit 만의 API는 바로 QuickTime X(10)다. 너무나 중요한 대목이다. 

애플이 주도하는 이런 API들은 강요하는 것이 아니라 자연스런 전환을 유도하는 것이기에 더욱 개발자들의 환영을 받고 있다. 물리적인 강요가 아닌 개발자 스스로 64비트 전환이 쉽게 이뤄지도록 주의깊게 고안된 것이라는 점이 포인트다. 

-------------------------------------------------

위 내용은 전문가를 위한 사라큐즈의 리뷰중 64비트만 발췌한 것입니다. 저같은 컴맹이 좀더 쉽게 이해하기 위해서 다음 글을 옮겼봤습니다.

http://www.ahatfullofsky.comuv.com/English/Programs/SMS/SMS.html

-------------------------------------------------

우선 맥에서 제공하는 지금 까지 인텔맥 제품은 다음과 같은 CPU를 장착하고 있습니다.

        1. 인텔 CoreDuo Processor는 32 bit CPU --> 스노우 레퍼드는 32비트로 작동합니다.
        2. 인텔 Core2Duo 64 bit CPU                       --> 스노우 레퍼드가 64비트로 작동할 수 있습니다.

애플에 따르면 스노우 레퍼드 장착 제품 대다수가 디폴트로 32비트 커널 모드로 작동 합니다. 위에서 언급한것처럼 디비디 플레이어, 아이튠스, Grapher등은 아직 64비트 어플이 아닙니다. 하지만 그외의 모든 64비트 소프트웨어들은 32비트 커널 모드에서도 64비트로 작동합니다! 

애플은 의도적으로 일부제품에 스노우 레퍼드 64비트 커널 모드에 제한을 걸었습니다. 64비트 EFI가 장착됐음에도 32비트 커널이 작동한다는게 바로 그것입니다.하지마 그렇다해도 모든 64비트 어플리케이션 (메일, 사파리, 파인더, 아이챗 등)이 64 비트로 작동합니다.

바로 드라이버 호환성 때문에 이런 제한을 걸어둔 것입니다. 다시 말하지만 32비트 커널모드로 작동해도 실질적인 사용에서 모든 64비트 프로그램은 64비트로 작동한다는 것입니다. 반대로도 마찬가지입니다. 만약 64비트 커널 모드로 부팅됐다해도 32비트 어플리케이션이 정상작동합니다.

따라서 스노우가 32비트 커널모드로 작동한다며 64비트 운영체제가 아니라고 하는것은 잘못된 지적입니다.

현재 문제가 되는 것은 Core2Duo 맥북과 맥에어 기종입니다. 64비트로 부팅하려해도 애플에서 블록을 걸어놨습니다. 애플의 의도적인 블록이며 곧 이에 대한 추가지원이 해결될 것으로 보입니다.


---------------------------------------------------------------------------------------------------------------------------


출처 : x86osx.com jp님의 글

http://x86osx.com/bbs/view.php?id=freeboard&page=1&sn1=on&divpage=4&sn=on&ss=off&sc=off&keyword=jp&select_arrange=reg_update&desc=desc&no=19806
Trackback 0 Comment 0

[눈범 진실] "눈범이가 서비스팩이라고라!!"





눈범이 출시 이전부터 많은 마빠/윈빠 언론들이 눈범이 비난을 퍼붓고 있습니다. 현재 진행형입니다. 이런 글을 보고 누군가 댓글 대응을 하면 "그래서 너는 애빠..."라고 물타기를 합니다...ㅋㅋ (이런거 보면 아이티업계 마빠 언론이나 조중동이나 비슷합니다...) PC World, cnet, informationweek 등등 사실 눈범이 관련 기사 10개중 8이 비판적으로 나옵니다. "별거 아니다." "업그레이드냐 엽그레이드냐." "가짜 64비트다."  구구절절 그 예를 들자면 셀수도 없습니다. 이런 일들이 벌어지고 있다는 것이죠.^^ x86osx의 저희들이야 스노우 좋은 점만 보게되지만 대다수는 그렇지 않죠. 쪽수에서도 10대 1이니...ㅋㅋ

제가 즐겨 글을 옮기는 다니엘 에런 딜거가 왜 조용한가 했습니다. 마침 저는 오늘 arstechnica.com에 게재된 장장 24페이지 분량에 달하는 장문의 스노우 리뷰를 읽고 너무나 기술적이고 개발자중심 글이라서 눈이 망가지더라구여...ㅋㅋ 헌데 이중 "스노우 레퍼드의 64비트 진실"은 저같은 컴맹들에게 좋은 정보를 제공했습니다. 그래서 옮기던 중이였습니다. 헌데 아니나 다를까 딜거의 글이 애플인사이더와 자신의 블로그에 턱하고 올라왔습니다. 그냥 지나치기 넘 아까워서 급하게 이것 먼저 옮기는 작업을 했습니다. 딜거가 칼을 빼든 이유는 바로 "논리적이지 못한 비판"에 대한 "논리적 반격"입니다. 

----------------------------------------
Inside Mac OS X Snow Leopard: QuickTime X

지능이 떨어지는 소위 아이티 전문가들이 스노우 레퍼드를 두고 "서비스 팩"(Service Pack)이라고 한다. 하지만 애플의 새로운 OS는 사실상 이미 알려진 바와같이 다양하고 중요한 맥 플랫폼의 새로운 시대를 열어주는  "확장 대로"다. 잘못 알려지고 오도되고 있는 눈범이 비판에 대해 이제 시리즈로 하나하나 잘못된 점을 고쳐주겠다. 그 첫회로 QuickTime X(10)이다. 

퀵타임 10

모두 알다시피 눈범이의 퀵타임 10은 이전 버젼에서 Pro로 업그레이드가 필요없이 풀스크린 무비 플레이가 가능한 것이다. 또 스크린 비디오 캡춰와 이를 유투브에 업로드할 수 있다. 하지만 이런 추가기능은 빙산의 일각이다.

단적으로 예를 들자면 애플은 퀵타임 7의 이런저런 기능을 눈범이에서 업그렐이드 시켜준게 아니라  iMovie 08을 통째로 넣어준 것이나 다를바없는 기능을 제공한다. 추가로 말하자면 퀵타임 10은 미디어 관련 개발자들에게 새로운 시대를 열어주는 플랫폼으로 처음부터 새롭게 제작된 것이다. 물론 아이폰의 무비 편집기능이나 임베디디 퀵타임 기능에서 더 발전시킨것으로 볼 수 있다. 

또 iMovie 08처럼 퀵타임 10은 7버전에서 벌도로 해야했던 많은 수행작업들이 필요없다. 퀵7의 경우 복잡한 트렌스 코딩 옵션을 제공해야 하거나 코덱 추가를 위해 콤포넌트 플럭인스의 인스톨을 해야했고, 또 퀵타임 스트림 서버와의 연동을 위한 RTSP 트랙등을 기록하는 작업을 개별적으로 해야만 했다. 바로 이런 이유 때문에 눈범이 설치때 애플에서 퀵타임 7.x 설치 옵션을 제공하는 것이다. 

반면 퀵10에서는 퀵7에서 해오던 복잡한 작업을 제거했다. 자동화된 트랜스코딩 그리고 웹상으로의 자동 업로드 그리고 풀스크린 파노라마 무비 재생, Trim Editing 컨트롤, 컬러싱크 지원, 스크린 캡춰 비디오 레코딩 등 모든 기능을 퀵10이 독립적으로 프로그램내에서 하도록 담아냈다. Pro 업그레이드가 필요없이 말이다.

HTTP Live Streaming

퀵10의 진정한 잠재력은 새로운 오픈소스 기반으로 웹상에서 영화 전송 그리고 온 디맨드 비디오 관련 표준인 HTTP Live Streaming 기능을 채택한 것이다. 만약 스트리밍되는 영화재생이 퀵10에만 적용된다면 별 의미가 없다. 하지만 이미 컨텐츠 전송 매체 네트웍들이 퀵10의 지원을 약속하며 애플에 줄을 서고 아이폰 3.0에도 HTTP Live Streaming 기능이 담겨있는 것이다.

의미인 즉, 모빌 클라이언트용으로 만들어진 4천5백만가지 컨텐츠가 HTTP Live Streaming 비디오로 전환될 수 있으며 애플은 퀵10으로 이런 컨텐츠를 적극 활용할 수 있는 유리한 업계 위치를 확보하고 있는 것이다.

APPLE TV 3.0

09 09 09 이벤트에서 과연 애플 티브이 업데이 여부가 초미의 관심사다. 아이팟과 더불어 업그레이드 되는 대상으로 기대를 모으고 있다. 하지만 중요한 사실은 HTTP Live Streaming이 애플티브이에서 작동하지 않을 이유가 없다. 천상의 궁합이기 때문이다. 다운로드가 필요없이 실시간 영화재생이 가능하다는 것으 의미하는 것이다. 

아이폰은 이미 값싸고 가볍고 유연한 오픈 프로토콜인 HTTP Live Streaming 기능을 이용해 가입자들에게 영화서비스 제공이 가능하다. 여기에 아이팟, 퀵타임, 애플티브이를 이용해 같은 서비스가 대기 중이다. 이것이야 말로 실시간 영화재생이나 온 디맨드 영화 전송의 궁극적인 목표다. 팟캐스팅이나 다를게 없다. 누구든지 퀵10 사용자는 별도의 RTSP 서버없이도 실시간 영화재생이 가능해졌다는 것이다.

여기에 애플이 가격까지 하락시키면 애플티브이의 저변화는 불보듯 뻔한 사실이다. 오픈 소스 기반의 HTTP Live Streaming은 사실 애플뿐만 아니라 피씨 사용자 및 리눅스 사용자들에게도 유익한 일이다. 따라서 마소가 미련을 버리지 못하고 있는 자기들만의 WMV 포맷으로 디지털 영상전송하려는 시도 역시 별 의미가 없어질 것이다.

QuickTime 10 Foundation

애플의 퀵10은 20년동안 구축해온 퀵타임 기술의 결정체이며 OS X 미디어 기능의 새로운 장을 여는 것이다. 64비트 코코아 기술과 OpenCL의 연동이 가능해졌기 때문이다. 미래 애플은 퀵10을 이전에도 가능했던 편집 플럭인스들을 더욱 발전시켜나갈 에정이다. 현재 파이널 컷은 이전 세대의 퀵타임과 카본 그리고 32비트 코드에 의존하고 있지만 머지 않은 장래에 코코아 기반의 퀵10 기반으로 풀 가동될 것이다. 

따라서 애플의 눈범이에 포함된 퀵10은 클라이언트 어플 개발자 뿐만아니라 일반 사용자들에게 미래를 열어주는 새로운 플랫폼 어플임을 입증하는 것이다.         



64비트 관련이야기가 후속으로 곧 준비될 예정입니다...


---------------------------------------------------------------------------------------------------------------------------


출처 : x86osx.com jp님의 글

http://x86osx.com/bbs/view.php?id=freeboard&page=1&sn1=on&divpage=4&sn=on&ss=off&sc=off&keyword=jp&select_arrange=reg_update&desc=desc&no=19790
Trackback 0 Comment 0

SnowOSX Universal 10.6 GM (10a432) v3.5




정식 Snow Leopard 가 출시되자 마자 해킨용 이미지가 나왔습니다. 아마도 이전에 유출된 GM버전이 최종 Retail 로 확정되면서 이미 토렌트에선 이미지가 돌고 있었지요.
러시아쪽에서 나온 녀석이라 그런지 영어와 러시아어 2개의 언어팩만 들어있습니다. 러시아용 언어팩을 지우고 한글용으로 교체후 한번 실치시도를 해봐야겠네요 ^^;;

포함된 app는 다음과 같습니다.

/ATools/
AppCleaner.app
BetterZip.app
CandyBar.app
Change Finder
Clone X 3.app
CPU-i.app
ForkLift.app
HexEdit
iGetter.app
IORegistryExplorer.app
KCNScrew.app
Kext Utility.app
Monolingual.app
OnyX.app
OSX86Tools.app
Property List Editor.app
TinkerTool.app
Xbench.app 

/ATools/_Drivers/
AppleACPIPS2Nub.kext
AppleIntelPIIXATA.kext
ApplePS2Controller.kext
AppleRTL8139Ethernet.kext
CPUi_snow.pkg
dsmos.kext (from Netkas to 10a432)
HDEFInject.kext
LegacyAppleAHCIPort.kext
LegacyAppleIntelPIIXATA.kext
LegacyAppleYukon2.kext
LegacyIOAHCIBlockStorage.kext
LegacyJMicronATA.kext
NVInject.kext
OpenHaltRestart.kext
PlatformUUID.kext
SleepEnabler.kext
SMBIOSResolver.kext
TARUGA_SNOW
VoodooHDA.kext 

/ATools/_System/
Beta_decrypter_for_10a421a_32_64.pkg
bootsnow-9-4
Chameleon_DFE_for_Hard_Disk.pkg
Chameleon-2.0-RC2-r640.pkg
/DSDTPatcherGUI_1.0/
EFIStudio.app
Pacifist_2.6.dmg
Trackback 0 Comment 0

WWDC의 개최일이 공개되었습니다.

사용자 삽입 이미지

2009년 WWDC의 개최일이 발표되었습니다. 6월 8일부터 12일까지 5일간 진행이 되는군요.

이번 WWDC에서 새로운 iPhone 과 Snow Leopard를 공개할것 같습니다.

아마도 3.0 펌웨어의 정식 발표도 있을거 같은 생각도 듭니다만

한국에 iPhone을 정식으로 출시한다는 확률은 아직까지 미지수입니다.

iPhone 떡밥만 어느새 1년이 넘었군요. 이젠 진짜 출시해줘도 되잖아!




http://developer.apple.com/WWDC/


Trackback 0 Comment 2
  1. motiv 2009.03.29 23:56 신고 address edit & del reply

    안나와 안나와 기대하지마 ㅋㅋㅋ;;

  2. mudica 2009.03.31 00:22 신고 address edit & del reply

    제길 ㅡㅜ

prev 1 next