제공 : 한빛 네트워크
저자 : Chris Josephes
역자 : 한일 / corone@empal.com
원문 : OpenSolaris: Driver Wrangling
나는 랩탑, 가상 머신, 그리고 테스트 서버 환경에서 지금까지 약 6주 동안 오픈솔라리스 2008.11을 사용해왔다. 나는 그 환경들에서 모든 것이 얼마나 잘 작동하는 지와 그 차이점에 관한 기사를 쓰겠다고 예전에 다짐했었다.
세 환경 중에서 랩탑이 설치 후에 가장 많은 작업을 필요로 했다. 내 랩탑은 Gateway MX6450이다. 그것은 AMD Turion 64 프로세서를 장착하고 있다. 이 모델은 적어도 2년은 된 모델이고, 발열과 배터리 전력에서 좋지 않은 평을 받고 있다. 그것은 또한 Vista가 정식 지원되지 않는 64비트 싱글 코어 시스템이다. 그래서 내가 지금 그것에 관하여 불평을 해도 Gateway에서 크게 신경을 써줄 거라고 생각하지는 않는다.
처음의 부팅과 설치 과정은 흠잡을 데 없이 잘 진행되었다. 그 일은 다른 리뷰어들이 언급했던 것과 같이 우분투 식으로 간단했다. 나는 Live CD를 실행하고 있는 동안에도, 그리고 하드 디스크로부터 부팅한 후에도, 모두 Device Driver Utility를 실행할 수 있었다. 두 경우 모두, 네 개의 동일한 에러를 보고했다.
네트워킹이 되지 않았다. 그러나 적어도 DVD 드라이브와 디스플레이는 작동되었다. 그리고 오디오 드라이버가 설치되었음에도 불구하고 작동되지는 않았다. 나는 설치를 계속 진행했다. 그래서 나는 하드 드라이브로부터 부팅할 수 있었다. 나는 작동되지 않는 것들을 대체할 수 있는 드라이버를 찾기 위해 구글링을 했다.
Yukon 드라이버 문제는 Marvell 웹사이트에서 간단한 다운로드로 해결됐다. 내가 해야 했던 것은 하나의 패키지 설치와 리부팅이 전부였다. 시스템이 리부팅되었을 때, DHCP 서버에 접속되어 어떤 수동 설정도 없이 IP주소를 할당 받았다. 나는 유용하게도 How To Fix The Audio Driver Problem In OpenSolaris라는 제목의 이 기사문의 지시에 따르는 것에 의해 오디오 드라이버를 해결했다. 나는 다시 설치 지시에 따랐고 시스템을 리부팅했다. 그리고 오디오가 작동되는 것으로 보상받았다.
여기까지, 내가 필요한 모든 것이 64비트 오픈솔라리스 설치에서 작동되었다. 불운하게도, Broadcom BCM4318 chipset을 위한 자체적인 지원은 없다. 무선 통신을 하려면 드라이버를 빌드해야 하고 오직 32비트 모드로 설정해야 할 것이다.
네트워크 드라이버를 사용할 수 없을 때, 드라이버에 의존하는 사용자들은 윈도우 드라이버를 가져와서 솔라리스 전용 드라이버로 빌드하기 위해 이 ndiswrapper 프레임워크를 사용하고 있다. 윈도우 드라이버를 복사하고 두 개의 프로그램을 컴파일 한 다음, 완료된 드라이버를 제 위치에 설치해라. 32비트 모드를 사용하기 위해서, 나는 GRUB 설정을 편집해야 했다. 나는 시스템을 리부팅 했고 몇몇의 Wi-Fi 무선랜전용지역에서 드라이버를 성공적으로 테스트했다.
나는 100% 완벽함을 기대하지는 않았다, 그래서 이것만으로도 충분히 만족한다. 내 랩탑은 오래된 모델이고 당신은 윈도우가 랩탑에서 가장 잘 지원되는 유일한 운영체제라는 것을 알게 될 것이다. 내가 사용할 중요한 애플리케이션은 파이어폭스, 썬더버드, 그리고 터미널뿐일 것이다.
만약에 당신의 컴퓨터에 오픈솔라리스를 설치해보려고 한다면 하드웨어 호환성 리스트 Hardware Compatibility List를 확인해라. 그것은 당신이 유저 리포트와 드라이버 유효성에서 찾게 될 최고의 자원이다.
제공 : 한빛 네트워크
저자 : Richard Monson-Haefel
역자 : 한일 / corone@empal.com
원문 : Google Native Client: A Game Changer or an Also-Ran?
지난 12월에 구글은 “구글 네이티브 클라이언트” (Google Native Client, NaCl)라고 하는 새로운 RIA 플랫폼을 발표했다. NaCl은 브라우저를 통하지 않고 x86 프로세서에서 C/C++ 애플리케이션을 직접 실행시키는 브라우저 플러그인을 제공한다. 구글은 개발 초기부터 이것을 오픈소스(BSD-style 라이센스)로 릴리스하고 있다. (“release early, release often!”)
구글 NaCl은 다른 많은 RIA 기술로부터 구조적인 관점에서 확실히 두드러진 발전이다. Silverlight, Flex, JavaFX 그리고 Ajax는 모두 네이티브 C/C++ 코드보다 느린 관리형 환경(Managed Environment)에서 실행되지만 다양한 운영 체제와 CPU에 더 잘 이식된다. 그러나, 가장 일반적인 3가지 데스크탑 운영 체제(윈도우, 맥 그리고 리눅스)가 모두 x86 CPU 구조에서 실행된다는 사실에서, CPU 이식성은 5년 전보다는 훨씬 덜 중요할 것이다. (물론, 그 코드를 스마트폰과 같은 다른 디바이스에서 실행시키기를 원하는 것이 아니라면.)
연구 프로젝트로조차 NaCl은 익사이팅한 동시에 무섭다. NaCl은 훨씬 더 좋은 성능을 보장하기 때문에 익사이팅하다. 이것은 그래픽이 강조된 게임, 3D, 그리고 데이터 시각화가 전보다 더 많은 잠재력을 갖는다는 것을 의미한다. 그러나 NaCl은 우리에게 지금까지 웹에 소개된 가장 보안이 보장되지 않는 기술 중 하나인 ActiveX를 상기시키기 때문에 무섭다. 그렇지만 ActiveX와의 비교가 공평할까? 구글에 따르면 NaCl은 ActiveX와 매우 다른 보안 구조를 사용한다. ActiveX는 다운로드된 애플리케이션이 운영체제를 자유롭게 통제하는 것을 허용한다, (ActiveX 컨트롤이 설치되기 위해 오직 당신의 동의만 필요하고 네이티브 애플리케이션이 할 수 있는 모든 것을 할 수 있다.) 반면에, NaCl은 해커에 의해 이용될 수도 있는 연산을 실행하기 위해서는 현재 존재하는 신뢰성 있는 라이브러리에 의존한다. NaCl의 이 초기 릴리스는 특히 최소한의 보안 문제들을 가장 쉽게 찾을 수 있는 보안 전문가들의 타겟이 되었다.
그래서 만약에 NaCl이 구글에서 말하는 것만큼 안전하고 또한 네이티브 런타임 성능도 제공한다면, 그것은 아마도 다른 많은 RIA 기술의 훌륭한 대안이 될 것이다. 그러나 성능은 대중 소비자 시장에서 개발자가 기술을 채택하는 중요한 요소가 아니다. 대중 소비자 RIA 애플리케이션의 개발자들에게 있어서 문제는 개발의 용이성이다. 그것은 사용하기 쉬운 개발 환경, 배우기 쉬운 언어, 미리 만들어 놓은 많은 컴포넌트들, 그리고 번영하고 있는 개발 생태계를 의미한다. 이 중에 어떤 것도 NaCl에 해당하는 것이 없다. NaCl 애플리케이션이 C/C++ 언어로 개발된다는 사실은(대부분의 RIA 개발자와 디자이너가 선택하는 언어는 아니다.) 개발자들에게 채택되는데 거대한 장애물이다. C/C++ 언어는 대부분의 RIA 개발자들에게 익숙하지 않을 뿐만 아니라 가파른 학습 곡선을 가진 까다로운 플랫폼이다.
물론 구글의 NaCl이 네이티브 혹은 네이티브에 가까운 런타임 성능을 위한 유일한 선택은 아니다. Curl은(주: 글쓴이는 Curl에 관한 일을 한다.) 10년 동안 네이티브 컴필레이션에 그 구조를 기초로 하였고 Windows, 맥, 그리고 리눅스에 모두 이식된다. 게다가 구글 크롬은 자바 스크립트 코드를 네이티브 코드에 컴파일한다. 자바 스크립트로 프로그래밍하는 것이 C/C++보다 훨씬 더 매력이 있다.
구글은 성능의 이점이 기업에서는 중요한 반면에 대중 소비자 애플리케이션에서는 시장 가치가 거의 없다는 것을 곧 알게 될 것이다. 대부분의 개발자는 그들이 현재의 RIA 기술을 갖고 벽에 부딪히기 전까지는 자체 성능에 관심을 갖지 않고 그 이후에는 테크놀로지 플랫폼을 바꾸기에 너무 많은 비용이 들 것이다. 대중 소비자 시장에서 NaCl이 채택되기에 큰 장애물이 될 것이 확실한 또 하나의 문제가 있다. NaCl 런타임 환경의 용량이 터무니 없이 큰 22MB이다. Mac에서 NaCl 이전에 RIA 기술에서 가장 큰 런타임 환경이 Java (15MB), Adobe AIR (12MB), Curl (9MB)이다. Flex의 plug-ins (5.5MB)와 Silverlight 2 (7.1MB)는 심지어 더 작다. Ajax는 거의 0에 가까운 용량으로 설치되는 기술이다.
NaCl은 성능의 이점이라는 매력적인 요소를 제공하는 반면에 NaCl이 경쟁력 있게 될 것이라거나 심지어 최종 릴리스에 다다를 것이라는 보장이 없다. 다른 더 잘 정착된 제품들이 대중 시장에 이미 포화상태이고 기업 개발자들은 “실험적”이라고 할 수 있는 기술을 채택하기가 어렵다. 그래서 NaCl은 흥미는 있지만 판도변화로써의 shoe-in은 아니다. 그렇지만 구글은 기대할 만한 힘이 있고 NaCl이 쉽게 사라지지는 않을 것이다.
