OpenSolaris with Corone

오픈솔라리스: 드라이버 논쟁

2010-01-01T00:00:00.000-08:00

제공 : 한빛 네트워크
저자 : 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를 확인해라. 그것은 당신이 유저 리포트와 드라이버 유효성에서 찾게 될 최고의 자원이다.

팀 브레이와의 인터뷰: Atom, JRuby, 그리고 the Ecumenical Sun

2009-03-21T00:00:00.000-07:00

제공 : 한빛 네트워크
저자 : Timothy M. O'Brien
역자 : 한일 / corone@empal.com
원문 : Interview with Tim Bray: Atom, JRuby, and the Ecumenical Sun

만약에 당신이 XML을 분석하거나 생성하는 어떤 시스템을 쓴 적이 있다면, 당신은 팀 브레이에게 어떤 빚을 진 것이다. 그는 1998년에 출시된 XML 1.0의 초기 설계서를 공동 집필했다. 그리고, 그것은 XML이 소개된 후 거의 10년간, 모든 프로그래머들과 많은 비프로그래머들에게도 친근한 개념이었다. 이런 성공을 했다면 사람들은 이미 얻은 명예에 만족할 지도 모른다. 그러나 브레이와의 대화에서 당신은 그가 XML에 대한 공헌으로 가장 알려져 있는 반면에, 이상하게 그가 다음 세대의 참여 기술 개발에 초점을 맞추고 있다는 느낌을 받을 것이다. 브레이는 Atom publishing protocol에 초점을 맞추고 있고. 오픈 소스에 공헌하고 있으며 웹 개발에 더 “에큐메니컬”한 접근을 향하여 Sun에 강요하고 있다. 가장 중요하게, 당신은 브레이가 더 투명한 인터넷을 창조하는 기술을 사용하려고 노력하고 있다는 느낌을 받을 것이다.

Sun을 더 투명하게

2004년에, Sun에서 발달된 블로깅을 만드는 데 도움이 된 것은 다른 임원들(핍스와 슈워츠)과 제휴한 브레이의 노력이었다. 여기 2004년 “Sun의 정책 결정”이라는 제목의 브레이의 블로그 글로부터의 발췌록이 있다, 그 글 안에서 그는 Sun의 더 자유로운 블로그 정책으로 가는 결정을 만드는 과정을 논한다.

소리 높여 이야기하기를 좋아하고 그것이 무장 공격일지도 모른다고 생각하는 많은 사람들이 거기에 있다는 것이 분명해졌다. 관리와 법적인 동의 없이 공공연히 소리 높여 이야기하는 것이 무장 공격이라고 말하면서 Sun이 지나간 해로부터 적소에 공식적인 정책을 가지고 있다는 것이 밝혀졌다. 이에 대한 조나단의 반응은 쓸 수 없었다.

그 때에 브레이는 더 투명해지기 위해서 그리고 커뮤니티에 대답하기 위해서 Sun을 격려하려고 노력하고 있었다. Java 플랫폼은 부적절함과 부진의 느낌으로 곤란을 겪고 있었다. 2004년 10월에, 오라일리 네트워크는 “Java의 상태”에 관한 특집 기사를 게재했다. 그 기사에서 많은 여러 편집자들이 Java가 어떻게 “시시하게” 되었는지 그리고 Java가 어떻게 “새로운 COBOL”이 되었는지에 관한 비평에 동의했다. 확실히, Java는 3년 전에 어떤 본질적인 위기를 갖고 있었다.

시간이 지나고 오늘날에 이르러 Java의 명성이 회복되고 있다. 그 플랫폼에 대해서는 여전히 고집스럽게 비방하는 사람들이 있고 항상 계속되는 논쟁이 있다. 그러나 그보다 적은 사람들이 그 플랫폼을 COBOL에 비교하고 있다. 우리는 JRuby같은 프로젝트나 F3같은 자고 있는 프로젝트가 Java, 플랫폼, Java의 한계 이상, 그 언어를 확장하기 시작했을 때를 창조력의 새로운 르네상스 시기로 보고 있다. 그리고 Java는 그 커뮤니티와 맞서기 위해 과거보다 더 많이 내부 직원들을 격려하고 있다.

최근에 브레이는 Three blogs.sun.com Years에서 3년의 Sun의 블로깅 정책에 대해 곰곰이 생각할 기회를 가졌다.:

그것은 Sun의 이미지를 개선하는 것을 도왔다. 3년 전에 우리는 크고 얼굴도 없고 변호사에 속박된 돌기둥처럼 보였다.; 지금 세계는 이들을 다루기 힘든 종족의 사람들이고, 많은 사람들이 영리하고, 광적으로 IT 기술과 사업에 빠져 있다고 본다.

슈워츠가 CEO로 임명된 이래로 Sun의 재정 실적은 “보통”으로 평가할 수 있다. 그리고, Sun은 핵심 서버 시장에서 쇠락하는 판매의 형태로 많은 도전과 HP와 IBM의 경쟁에 직면해 있다. Sun은 Solaris와 JDK의 소스 공개로 인해 변화하는 개발자의 전망에서 승리한 적이 있다. Java를 플랫폼으로 부활시키는 데 대해 브레이에게 유일한 공을 돌리는 것은 부적당할 것이다. 그러나, 명백히, 브레이의 투명성에 대한 헌신과 커뮤니티 참석을 위한 분발 요구는 인식을 바꾸는 데 중요한 역할을 했다. 시간은 인식에서의 이 변화가 Sun의 서비스 부분을 지지하는 것을 돕는지 말해줄 것이다, 그리고 기업의 사회 공헌이 그 최종 결과에 영향을 미치는지 말해줄 것이다.

인터뷰

팀 브레이는 최근에 Atom protocol에 대한 현재의 그의 일, JRuby에 대한 그의 전망, 그리고 Sun의 점진적으로 발전하는 웹 전략에 관하여 O'Reilly Network에게 이야기하기 위해 그의 바쁜 스케줄을 벗어나 얼마 동안의 시간을 가졌다. 그 내용은 다음과 같다.

팀 오브라이언: Sun Microsystems의 디렉터로써의 당신의 역할 중에, 당신은 어디에 초점을 두고 있는가? 당신의 그날그날의 책임은 무엇인가?

팀 브레이: 나는 종합적인 일을 하는 사람이다. 나는 운영체제에서부터 웹 분야를 넘어, 응용 계층까지 모든 것에 흥미가 있다. 실제로 Sun에는 종합적인 일을 하는 사람들이 아마도 조금밖에 없는 것 같다. 분명히 우리는 자바와 운영체제, 그리고 그런 분야들에서 세계 수준의 전문가를 갖고 있다. 그러나 나는 더 다양한 계층에 익숙한 사람이다.

그래서, 나는 내가 관심을 갖는 것 내에서는 자유재량을 가지고 있다. 분명히, 그것은 밖에서 사람들이 이야기하는 것을 듣는데 시간을 보내는 것도 포함한다. 나는 많은 회의에 참석한다. 나는 본사의 몇몇 내부 회의에도 꽤 참석한다. 많은 부분에서, 나는 의사를 나누는 사람이다. 나는 항상 소프트웨어를 다루고 있고, 보통 몇몇 종류의 진행중인 개발 프로젝트를 가지고 있다.

오브라이언: JRuby 프로젝트에 집중하면서 나는 당신으로부터 Jira 버그 보고서가 있었다는 것을 알게 됐다. 당신은 당신이 의사를 나누는 사람이라고 말했는데 당신은 특별한 프로젝트에서 얼마나 활동적인가? 당신은 Glassfish같은 프로젝트나 JRuby같은 프로젝트에 참가한 사람들을 감독하고 있는가?

브레이: 나는 어떠한 직접적인 보고서도 가지고 있지 않으며 사람들을 전혀 감독하지도 않는다. 나는 JRuby를 사용한다, 그리고 그것이 아직 시험적인 것이기 때문에 내가 버그들을 찾은 것이다. 당신은 또한 가끔 NetBeans에서 내가 버그를 보고한 것을 알 것이다. 나는 그것들이 내가 지난해에 실제로 버그를 보고했던 오직 두 개의 프로젝트일 것이라고 생각한다. 아니다. 나는 또한 어떤 핵심 Ruby 버그를 보고했다. 그 외에 무엇이 있는지 생각해 보자. 나는 Ruby on Rails에 각별히 신경을 쓴다. 그리고 그것들은 내가 정말로 각별히 주목하고 있는 유일한 것일 것이다.

잠깐, 아니다. 내가 각별히 주목하는 두 개의 내부 프로젝트가 있다. 그것들은 아직 발표되지 않았다. JavaOne에 관하여 알아보라.

오브라이언: 현재 진행중인 APE 같은 소프트웨어 프로젝트들에 관련이 있다. APE가 무엇인가?

브레이: 나는 IETF Atom Working Group의 공동 의장을 맡는다. 그리고 현재 그 Atom Working Group을 거의 끝낸 것이 Atom Protocol이다. 그리고 나는 표준에 따라 일하는 과정에서, 당신이 표준을 쓸 때, 그것이 동시에 표준을 따르려고 하는 것을 정말로 돕게 된다는 것을 발견한 적이 있다. 왜냐하면 그때 당신은 무엇이 일을 하고 무엇이 일을 하지 않는지를 배우게 된다. APE는 Atom Protocol Exerciser을 나타낸다. 그것은 Atom protocol 클라이언트가 할 모든 것들을 모방하는 프로그램이다. 그것은 Atom protocol을 이행하는지 테스트하기 위해 사용된다.

나는 내 스스로 그것을 썼다. 그리고 우리는 이번 주에 실제로 Google에서 Atom protocol 상호이행 행사를 가졌다. 그리고 그것은 정말로 성공적이었다.

오브라이언: 나는 Wiki에서 호환성 차트를 봤다. 그것은 흥미로워 보였다.

브레이: 그것은 아주 재미있는 행사였다.

오브라이언: Atom protocol로, 당신이 이번 주에 당신의 블로그에 “그 클럽은 얼마나 큰가?”라는 글을 썼다. 이 글에서 당신은 많은 사람들이 정말로 그것이 무엇인지 이해한 것이 아니라는 것을 보여주기 위해서 어떤 회의의 연설과 Twitter 블로그 글을 언급한다. Atom을 쓰면서 그런 적이 있었는가? 당신은 Atom 지지자가 얼마나 크다고 생각하는가? 누가 Atom에 정말로 관심을 갖는가?

브레이: 그 순간에 Atom에 관심을 갖고 있는 유일한 사람들은 프로그래머와 표준을 따르는 사람들이다. 무엇보다도 신디케이션 공간에서, 그리고 다음으로는 일반 웹 테크놀로지 공간에서 그렇다. 그것은 훌륭하다. 비슷하게도 우리가 10년 전에 XML을 개발하고 있었을 때 관심을 갖고 있었던 유일한 사람들은 표준을 따르는 사람들이었다는 것을 지적하고 싶다.

Atom은 XML처럼 일반 사용자에게 보여지는 것이 아니다. 다시 말해서, 만약에 그것의 애플리케이션에 대한 우리의 꿈과 희망이 실현되었다면 그것은 웹의 일반 사용자의 경험에 정말로 극적인 충격을 받을 것이다. 그러나 마지막에는 사람들이 경험하게 될 것들을 가능하게 한다.

오브라이언: 대부분의 사람들은 Atom을 RSS 같이 생각한다. 그것은 “단지 신디케이션 포맷”이라는..

브레이: ...글쎄, Atom은 두 가지가 있다. 첫 번째는 물론 신디케이션 포맷이다. 그래서 Atom 데이터 포맷은 RSS가 개발되었던 해에 우리가 배운 것에 기초하는 본질적으로 단지 RSS의 돈벌이이다. 그리고 그 일은 RFC4287로 이미 완성되었다; 그것은 이미 완성되었고 꽤 널리 사용되어 보급되었다.

Atom의 다른 반쪽은 우리가 전에 얘기했던 Atom publishing protocol이다...

오브라이언: Atom publishing protocol은 웹을 어떻게 변화시킬 것인가? 대부분의 사람들은 그것을 신디케이션 포맷으로써만 알고 있다. Publishing protocol에 대해서 말해 달라.

브레이: 당신은 MetaWeblog API라는 것을 들어본 적이 있을지도 모른다. 그것은 어떤 블로깅 시스템이 퍼블리싱을 지원하기 위해 사용하는 것이다. 그것을 하기 위해 노력하고 있다.

여기 꿈이 있다; 모든 것이 퍼블리시 버튼을 가지고 있어야 한다. 모든 스프레드 시트, 모든 휴대폰, 모든 카메라, 모든 뉴스 리더, 모든 메일 리더, 모든 워드 프로세서가 퍼블리시 버튼을 가지고 있어야 한다. 당신이 스크린에서 당신이 좋아하는 것을 보자마자 당신이 퍼블리시 버튼을 누를 수 있고 웹에서 그것을 가질 수 있어야 한다. 그리고 웹에서 퍼블리시 할 수 있는 다른 많은 곳이 있다는 사실을 준다. 내 말은, 아마도 당신이 Blogspot에 있든지, 아마도 당신이 Facebook에 있든지, 아마도 당신이 LiveJournal에 있다면... 무엇이든지; 더 많은 것이 올 것이다. 확실히, 당신은 퍼블리시 버튼을 가진 어떤 것이 퍼블리시하는 것과 의사소통을 사용할 수 있는 uniform protocol의 어떤 종류가 필요하다.

Atom은 그 꿈을 가능하게 디자인하는 최상의 HTTP 계층인 매우 가벼운 protocol이다. 우리가 이번 주에 구글에 있는 방에서 보았던 것에 기초하여 나는 우리가 그 꿈을 실현시켜 주는 일을 잘 한다고 생각한다.

오브라이언: 가상으로, 당신이 뉴욕 타임즈나 BBC같은 곳에서 일한다. 그리고 이미지에서부터 뉴스 스토리까지 모든 것을 찾아내는 Content Management System (CMS)가 있다. 당신은 Atom을 모든 콘텐트 타입에 대해 확장할 수 있는 것으로 보는가? 그것이 당신이 Atom을 가지고 하려고 하는 일인가? 아니면, 그것이 단지 블로그에 대한 것인가, 단지 포토스트림에 대한 것인가, 단지 스프레드시트에 대한 것인가? 당신은 일반 콘텐트 저장소에 대한 기초를 세우려고 노력하고 있는가? 기업 콘텐트 관리 시스템에서 사용될 수 있는 것인가?

브레이: 글쎄, 나는 내가 개발을 도운 일반 목적 기술의 애플리케이션에 대한 매우 잘못된 연속적인 예견을 했다. XML이 무엇에 사용될 지에 대한 나의 예견은 명백히 틀렸다. Atom protocol의 디자인 센터는 확실히 블로깅이었다. 다시 말해서, 우리는 이미 블로그가 아닌 애플리케이션을 알고 있었다. 예를 들어, 오라일리에서 당신의 동료 두 명이 interop event에 왔고 블로깅을 할 수 없는 Atom 서버 이행을 했다.; 사실 APE는 그것들과 서로 영향을 끼치지 않는다. 왜냐하면 그것들이 업로드할 수 있는 유일한 것은 DocBook XML이다. 우리가 하려고 하는 것은 블로그 공간을 위해 유용하고 생산적인 정말로 좋은 일을 하는 것이다.

나의 예견은 내가 예견하기에는 내가 정말로 충분히 머리가 좋지 않고 나를 놀라게 할 많은 애플리케이션이 나올 것이라는 것뿐이다.

오브라이언: 그러면, 그것이 Atom의 한 부분인 확장 메커니즘을 거치는가?

브레이: 그렇다, 그러나 그것은 우리 컴퓨터 프로그래머들이 CRUD 동작이라고 하는 생성(Create)-수정(Retrieve)-갱신(Update)-삭제(Delete)를 하는 아주 단순한 방법을 갖춘 단지 기본적인 기능이다. 웹에 자료를 올리는데 표준을 이행하는 간단한 마음가짐을 위한 일반 목적의 단순한 기능이다. 그것들이 거기에 있는 즉시 그들을 업데이트하고 당신이 그것들을 더 이상 원하지 않으면 지운다. 그것은 단지 그것 자신에 의해 많은 흥미로운 애플리케이션을 가질 것이다.

오브라이언: 우리의 RSS 제공은 그만두게 될 것인가?

브레이: 당신은 왜 그렇게 생각하는가? 미안하지만, 이해할 수 없다. RSS는 세계에서 가장 성공적인 XML의 애플리케이션이다, 그리고 그것은 정말로 수백만의 사람들에 의해 사용되고 있다. 나는 무언가를 놓치고 있다...

오브라이언: 내 말은, Atom에 있어 전반적으로 전환할 것인가? 그것이 우리의 RSS 제공을 그만두게 될 것인가?

브레이: 아, 당신이 무슨 말을 하는지 알겠다. 글쎄, RSS는 단지 기본적인 개인 대 개인의 블로그에 대해서만 잘 동작하는 것처럼 보인다. 나는 그 선택을 받은 표준을 따르는 사람들 대부분이 차라리 Atom을 가지고 일을 하고 싶어 할 거라고 생각한다. 왜냐하면, 그것은 RSS에서 짜증나는 사소한 결함들을 해결해 준다. 만약에 당신이 컨텐츠 제공을 하기 위한 설비를 쓰고 있다면, 당신은 RSS와 Atom을 둘 다 사용해야 할 것이다. 그리고 그것이 더 나쁘다면 당신은 RSS의 다중 버전을 사용해야 할 것이다. 왜냐하면 그것은 그런 식이다. 다시 말해서, 만약에 당신이 컨텐츠를 제공하는 새로운 것을 사용하고 있다면, 당신은 Atom을 생성하는 것이 좋을 지도 모른다. 왜냐하면, 그것이 훨씬 더 깨끗하고 그 이외에 당신을 괴롭힐 지도 모르는 어떤 버그들을 벗어날 것이다. 컨텐츠 제공을 읽는 그 외의 모든 소프트웨어도 지금 Atom을 읽을 수 있다.

오브라이언: 당신은 Atom 앞에서 RSS가 사라질 것이라고 보는가? 아니면 사람들이 둘 사이에 상호 작용을 가질 것이라고 보는가?

브레이: 나는 프로덕션에 가져오는 새로운 컨텐츠 제공이 점점 Atom에서 있을 거라고 생각한다. 우리는 이미 그것을 알고 있다. 그러나 인터넷에 있는 기술들은 사라지지 않는 경향이 있다. 당신은 그 외에 HTML에서 여전히 블링크 요소를 사용하는 그 밖에 많은 것들이 있다는 것을 안다. 그래서, 나는 앞으로 RSS가 대량의 넷에 공급하게 될 거라고 확신한다.

오브라이언: 당신은 사람들이 Atom에 관하여 놓치고 있다고 생각하는 것이 있는가? 아니면 당신은 그것이 커버되었다고 생각하는가?

브레이: 나는 아직 많은 사람들이 Atom Publishing Protocol을 알지 못한다고 생각한다. 지금 우리의 interop event의 tune에 의한 판단으로는 아는 사람들 또한 많다, 그러나 나는 지금으로부터 2년 내에 Atom Publishing Protocol이 정말로 대단한 것이 될 지는 의심스럽다.

나는 짧은 순간에 그것이 내 묘비의 XML을 닦을 기회를 가졌다고 말한다.

내가 이해시키려고 하고 있는 키 포인트는: 모든 것이 퍼블리시 버튼(Publish button)을 가져야 한다는 것이다. 왜냐하면 넷에서 우리가 더 많은 제공자를 가질수록 넷이 더 좋아지기 때문이다. 넷으로 더 많은 정보 자료들이 갈 수 있도록 마찰을 줄이기 위해 우리가 기술적으로 할 수 있는 것은 어떤 것이라도 좋은 것이다. 그리고 그것은 Atom이 하려는 것이다. 중요한 것은 사람들이 단지 읽는 것만이 아니라 제공하게 하는 것이다.

오브라이언: 당신은 Canonical과의 제휴에 관하여 알고 있었나?

브레이: 글쎄, 그것은 거의 비밀이 아니었다. 마크 셔틀워스는 지난 해 JavaOne에 참석했고 그와 조나단 [슈워츠]이 무대에서 입을 맞췄다. 그래서 Sun과 Canonical이 동료라는 것은 거의 비밀이 아니다.

오브라이언: 그때에 JaveOne에서 마크 플레리 또한 무대에 있었다, Red Hat과는 비슷한 제휴가 없었나? Red Hat과의 제휴 비용에서 당신이 Ubuntu의 편을 들고 있다는 추측이 사실인가?

브레이: 글쎄, 지난 주까지는, 우리가 JDK, NetBeans, EE, 그리고 이런 모든 다른 것들에 허가에 대한 문제를 가지고 있었기 때문에 당신은 어떠한 Linux 배포판 안에도 좋은 방법으로는 그것들을 넣을 수 없었다. 우리는 1년 전에 이런 것들의 소스를 공개하기로 정책 결정을 했다. 그러나, 아마도 당신이 아는 것처럼, 허가 권리와 그 밖에 여러 가지를 얻기 위해 돌아다닐 많은 법적인 메커닉이 있다. 그리고, 그것은 거대한 양의 일을 가져왔다. 나는 발표 얼마 전에도 그 일을 하고 있었다는 것을 알게 되었다.; 점을 찍기 위한 많은 i와 십자 줄을 긋기 위한 많은 t가 있었다. 지금 그것은 끝마쳤다. 어떤 리눅스 배포판에서도 Java를 설치하고 사용하는 것이 매우 매우 쉽다는 것은 매우 그럴듯하다.

Canonical은 올라서서 Ubuntu를 가지고 그것을 한 첫 번째 회사이다. 그러나 나는 그것을 하지 않는 어떠한 메인 리눅스 배포판도 상상할 수 없다.

당신이 왜 Java 설치하는 것을 쉽게 만들지 않겠나?

오브라이언: 자유 소프트웨어 커뮤니티에서 사람들로부터의 논쟁은 저작권 허가에 의해 방해 받는 코드의 부분이 여전히 있다는 것이다. 당신은 어떤 대답을 갖고 있는가?

브레이: 그것은 사실이다. 여전히 방해 받는 부분이 있다. 우리는 그것에 관하여 완전히 공개했다. 그 중에서도 나는 그것이 낮은 레벨의 Java SE 그것 자신에 있다고 생각한다. 몇몇의 예는 2D 그래픽과 폰트 렌더링이다. 우리는 그것을 계속 수정하면서 일하고 있고, 게다가 그것으로 커뮤니티를 위해 도울 희망을 가지고 있다. 전형적으로, 상업적인 제품이 공개되는 것은 언제든지 일어나는 일이다. 그것은 당신이 0에서부터 모든 것을 할 수 있는 이원 스위치가 아니다.

그렇게 말하는 반면에, 우리는 Canonical과 일을 하고 변호사를 고용하면서 ...그 안에 있는 방법을 생각해 낼 수 있었다.

오브라이언: ...다중우주...

브레이: 그렇다, 그것은 다중우주에 있다. 나는 Ubuntu의 권위자가 아니다. 나는 Red Hat에서 대응되는 것이 무엇인지 확실히 모른다. 그러나 그들은 그것이 Ubuntu에서 일어나게 만드는 방법을 발견했다. 그래서, 나는 어떠한 다른 리눅스 배포판에 대해서도 그것을 하는 것이 불가능할 것이라고는 상상할 수 없다.

오브라이언: 거기에 적의는 없는가?

브레이: 내가 아는 것이 아니다.

그것은 확실히 개발자 커뮤니티에서 바로 지금인 경우이다. Ubuntu는 “강한 마법”을 가졌다. Ubuntu는 많은 비율의 개발자의 주목과 애정을 정말로 약속하고 있다. 그리고 나는 Sun의 밖에서만큼 Sun 안에 Ubuntu를 향한 큰 애정이 있는 많은 사람들이 있다고 생각한다. 당신이 디지털 카메라에 연결하고 그것이 단지 작동하고 그 같은 여러 가지의 일을 한다.

오브라이언: JaveOne에서 나올 예정인 발표를 추측할 수 없다. 우리는 JRuby가 마무리되는 것을 기대할 수 있는가? JRuby 주위에 활동의 혼란이 있다는 것이 나타났다.

브레이: 활동의 혼란이 있다는 것은 너무도 명백하다.

오브라이언: 우리는 무엇에서 새로운 소식을 기대할 수 있는가? JRuby와 NetBeans? JRuby와 Glassfish certification?

브레이: 나는 예고에 대해서는 의견을 말할 수 없다.

하나만 말하겠다. 나의 견해는 JRuby에서 힘든 일을 실제로 가장 잘 다루는 사람이 Rails를 잘 작동시킨다는 것이다. 모든 Rails를 갖추는 것이 테스트를 통과하고 실제의 큰 Rails 애플리케이션을 매끄럽게 실행시킨다. 나는 그것이 Glassfish보다 아주 조금 더 많은 일을 하게 한다고 생각한다.

오브라이언: 나는 두 시간마다 이메일을 사용하고 그것들이 더 가까워지고 있는 것 같이 보인다. 찰스는 Rails가 지지 받을 때까지 JRuby를 고려하지 않을 거라고 말한 적이 있다. 그는 또한 Java에서 웹 개발의 어려움에 관하여 대중 연설을 한 적이 있다. JRuby와 Rails의 받아들임은 JavaServer Faces의 대안이 필요하다고 인정한 것인가?

브레이: 어떻게 설명할 수 있을까? 글쎄, 나는 우리에게 얼마나 많은 대안 프레임워크가 필요한 지 확실히 알지 못한다. 만약에 당신이 경험에 의존해서 그 시장을 본다면 많은 다른 프레임워크를 사용하는 개발자들과 다양한 웹 프레임워크를 사용하는 사람들이 있을 것이다, 둘 다 Spring과 Hibernate와 같은 공식적인 EE와 단순한 것들이다.

사람들은 PHP를 사용하고 있다, 정말 많은 사람들이 PHP를 사용하고 있다. Rails는 엄청난 성장 곡선을 그리고 있다. Python 커뮤니티로부터 사람들이 Django만큼 가까운 주의를 기울이지 않는 다른 것들이 있다. 나는 Sun이 그것처럼 세상에 존재할 필요가 있다고 생각한다. 그리고 그것처럼 세상에, 다른 많은 웹 프레임워크가 있고 모든 이런 웹 프레임워크가 실행하기 위한 iron과 그것들을 지원하기 위한 운영 체제가 필요한 애플리케이션을 만드는데 익숙해지고 있다. 나는 Sun이 우리가 할 수 있는 최고로 그들 모두를 사랑하려고 하지 않아야 하는 어떤 이유도 알지 못한다.

오브라이언: 그렇다면, JRuby on Rails가 JavaServer Faces와 경쟁을 하는 것이 아니다. 당신은 여전히 둘을 하나로 보는가?

브레이: 이것들 중 어떤 것도 사라지지 않을 것이다.

내가 갖고 있는 한가지 관심사는 Sun이 지난해 내내 Ruby on Rails와 기타 여러 가지에 관하여 매우 열정적이었다는 것이다. 그것은 PHP와 Django같은 것들을 무시할 수 있는 여유가 있다는 의미가 아니다. 나는 우리가 이런 모든 것에서 좋은 호스트가 될 필요가 있다고 생각한다. 그렇게 말하는 반면에, 나는 Rails가 매우 중요한 두 가지 조건의 시기(판매와 유지보수)에 웹 프레임워크에서 충격의 중심을 치고 있다는 것은 단지 Sun내에서만이 아니라 매우 널리 알려진 견해라고 생각한다.

오브라이언: 당신은 당신의 블로그에서 Seaside를 언급했다. 당신은 Seaside에 주목하고 있는가? Seaside에 관해 무엇이 당신의 흥미를 끄는가?

브레이: Seaside가 다른 모든 웹 프레임워크와 구조적으로 아주 다르다는 것은 분명하다. 당신은 여기를 경계해야 한다, 왜냐하면 내가 DabbleDB의 한 투자자로써 흥미 있는 분쟁을 하고 있기 때문이다. 그래서, 나는 거기에 진짜 돈을 가지고 있다. 그렇게 말하는 반면에, 내가 그 소프트웨어에 그렇게 깊은 감명을 받은 이유는 그것이 어떻게 만들어졌는지가 아니라 그것이 하는 일이다. DabbleDB는 완전히 훌륭한 사용자 인터페이스를 가지고 있고 나에게는 그것이 굉장히 유용한 어떤 것을 하는 것처럼 보인다. 나는 그것이 Seaside에서 만들어졌다는 것을 알았을 때 깜짝 놀랐다. 그러나, 분명히 그것의 존재는 Seaside가 유용하다는 매우 설득력 있는 증거다.

오브라이언: 그래서 Seaside는 주목을 받을 만한 것인가?

브레이: 나는 DabbleDB가 주목을 받을 만한 것이라고 생각한다. 그건 단지 그것을 만든 두 사람이 다른 프레임워크를 사용하는 것 같이 어떤 무언가를 생산할 수 있는 그런 훌륭한 디자이너인 경우에만 일지도 모른다. 그것은 적어도 Seaside가 흥미로운 것들을 만드는 데 익숙해 질 수 있다는 증거의 존재이다.

오브라이언: 나는 단지 당신에게 JRuby, 그리고 다른 웹 프레임워크에 관하여 일련의 질문들을 물었다. 그리고, Sun이 스크립팅을 받아들인 것에 관하여 더 복잡하고 더 적극적이 되고 있다는 것을 알 수 있었다. 그밖에 하고 싶은 말이 더 있는가?

브레이: 나는 Sun이 조금 변하려고 노력하고 있다고 생각한다. 지난 해까지는, Sun의 기본적인 위치가 “글쎄, 그 대답은 Java인데, 그 질문은 무엇이었는가?”였다. 그리고, 내가 우리가 더 에큐메니컬하게 되려고 노력하고 개발자들을 그들이 있는 곳에서 지지하려고 노력한다고 생각하기는 하지만, 그것이 우리가 어떤 견해도 가지고 있지 않다는 의미는 아니다. 분명히, 우리는 Java가 넓은 영역의 애플리케이션으로 아주 알맞다고 생각한다. 오늘날 우리가 Ruby 드럼을 두드리고 있다는 것을 알아 챘다면 그것은 올바르다. 그러나 그것이 당신이 PHP를 쓴다고 우리가 당신을 사랑하지 않는다는 뜻은 아니다.

우리는 더 에큐메니컬하게 될 필요가 있고 개발자들에게 그들이 어디에 있던지 접촉할 필요가 있다.

오브라이언: 당신은 JavaOne의 이름을 (JavaRubyPHPPython)One으로 바꿀 어떤 계획을 가지고 있는가?

브레이: 나는 그것에 대해 어떤 의결권도 갖고 있지 않다.

구글 네이티브 클라이언트: 판도변화 아니면 실패작?

2009-03-20T00:00:00.000-07:00

제공 : 한빛 네트워크
저자 : 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이 쉽게 사라지지는 않을 것이다.

오픈 솔라리스에 gcc 설치하기

2009-03-11T09:01:00.000-07:00

오픈 솔라리스에 GNU C 컴파일러인 gcc를 설치하고 간단한 예제 소스를 컴파일한다.

오픈 솔라리스에서는 패키지 매니저를 이용해서 gcc를 쉽게 설치할 수 있다.

pkg search gcc 명령으로 gcc가 정상적으로 설치되었는지 확인할 수 있다.
-r 옵션을 사용하면 리파지토리를 확인할 수도 있다.
# pkg search -r gcc

예제 소스를 만들고 컴파일을 해본다.
vi를 실행해서 코딩한다.

# vi test.c

세상에서 가장 유명한 프로그램인 Hello, World 이다. 저장하고 빠져나온다.

gcc test.c라고 gcc를 실행하면 test.c 파일을 컴파일하고 실행 파일을 생성한다. ls 명령어로 a.out 실행 파일이 생성되었음을 확인할 수 있다.

# ./a.out

실행 파일을 직접 입력하면 바로 실행된다.

gcc 명령으로 컴파일하면 실행파일은 항상 a.out로 생성된다. 실행 파일의 이름을 임의로 지정하려면 -o 옵션을 사용한다.

실행 파일은 자동으로 실행 권한이 생긴다.

ZFS 스냅샷 기능의 간단한 실습

2009-03-02T00:00:00.000-08:00

ZFS (Zettabyte File System)는 오픈 솔라리스의 기본 파일시스템이다.
ZFS는 대용량의 확장성, 완벽한 데이터 무결성 보장, 간편한 시스템 관리 작업 등을 제공하며 기존에 솔라리스에서 사용하던 UFS (Unix File System)를 대체하기 위해 개발된 더 강력해지진 파일시스템이다.

ZFS 스냅샷은 파일시스템 백업과 복구를 위한 아주 간단하고 강력한 기능이다.

ZFS의 스냅샷 기능을 간단한 실습으로 이해할 수 있다.

/export/home 디렉토리로 이동한 후 현재 위치를 확인한다. 현재 디렉토리 내에 osol-0811.iso 파일이 있다. 이 파일은 오픈 솔라리스 설치CD 의 iso 이미지 파일로 용량이 687MB이다.

ZFS 파일시스템의 스냅샷을 생성한다.

현재 디렉토리 내에 있는 osol-0811.iso 파일을 삭제한다. ls 명령어로 파일이 삭제되었음을 확인할 수 있다.

앞서 생성한 스냅샷으로 롤백하여 이전 상태로 되돌린다.

삭제되었던 파일이 스냅샷 롤백으로 간단히 복구되었음을 확인할 수 있다. 이처럼 스냅샷을 생성하면 특정 지점의 상태를 저장해 두었다가 필요할때 아주 간단하게 되살릴 수 있다.

더 놀라운 것은 스냅샷을 생성하고 롤백하는 시간이 1초도 안걸린다는 것이다. 스냅샷을 생성하는데 0.228초, 롤백하는데 0.543초 걸렸다.

오픈 솔라리스에서 고정IP주소 사용하기

2009-03-01T00:00:00.000-08:00

VMware에서 호스트 PC가 현재 속해 있는 네트워크에 게스트 PC가 직접 연결된 것처럼 사용할 수도 있다.

호스트 PC는 윈도우 XP, 게스트 PC는 오픈 솔라리스이고

호스트 PC의 IP주소는 192.168.0.101
서브넷 마스크는 255.255.255.0
라우터의 게이트웨이 주소는 192.168.0.1 이라고 하자.

게스트 PC의 IP주소로는 192.168.0.102를 사용하고
(서브넷 마스크 255.255.255.0)

DNS 서버 주소는 168.126.63.1과 168.126.63.2를 사용할 것이다.

VMware에서 'Edit virtual machine settings'를 클릭하거나 [VM] - [Settings]를 클릭하여 Virtual Machine Settings 창을 연다.

왼쪽 창에서 Ethernet을 선택하고 NAT로 설정한 네트워크 연결 설정을 Bridged로 변경한다.

오픈 솔라리스의 바탕화면을 마우스 오른쪽 버튼으로 클릭하면 나타나는 팝업 메뉴에서 '터미널 열기'를 클릭하거나 [프로그램] - [시스템 도구] - [터미널]을 클릭하면 터미널 창이 나타난다.

터미널에서 필요한 설정은 아래와 같다. 이 설정을 위해서는 vi 편집기와 터미널 사용법을 알아야 한다.

# cat /etc/hosts
(중간 생략)
192.168.0.102 opensolaris

# cat /etc/defaultrouter
192.168.0.1

# cat /etc/resolv.conf
domain localdomain
nameserver 168.126.63.1
nameserver 168.126.63.2

# cat /etc/nwam/llp
pcn0 static 192.168.0.102/24

# cp /etc/nsswitch.dns /etc/nsswitch.conf

# ifconfig pcn0 plumb 192.168.0.102 up

이제 게스트 PC는 실제 라우터와 직접 연결된 호스트처럼 작동한다.

이 설정은 VMware에서뿐만 아니라 일반 네트워크에서도 고정 IP주소를 사용하기 위해서 오픈 솔라리스에 설정할 수 있다.

또한, 솔라리스 10 등의 다른 솔라리스에서도 이 설정은 동일하다. 단, 위의 설정 중 /etc/nwam/llp 파일 설정은 다른 솔라리스에서는 필요없다.

인터넷 접속이 가능하다.

VirtualBox에서 가상 머신 만들기

2009-02-10T00:00:00.000-08:00

VirtualBox 다운로드 페이지: http://www.virtualbox.org/wiki/Downloads

썬 마이크로시스템즈 VirtualBox 사용자를 위한 VirtualBox에서 가상 머신 만들기이다.
VirtualBox에서 오픈 솔라리스를 설치하기 위한 가상 머신을 만든다.

VirtualBox를 처음 설치하면 아래와 같은 화면이 나타난다.

위에서 '새로 만들기' 버튼을 클릭하거나 [머신] - [새로 만들기]를 클릭하여 새 가상 머신 생성 마법사를 실행시킨다.

새 가상 머신 생성 마법사가 실행되면 '다음'을 클릭한다.

가상 머신의 이름은 가상 머신의 관리 및 설정을 위한 이름이다. 본인이 원하는 이름을 아무 이름이나 지정하면 된다. 설치할 운영체제를 잘 나타내는 이름으로 정하는 것이 좋다.
설치할 운영체제를 선택한다. 오픈 솔라리스를 설치할 것이므로 운영체제에 'Solaris', 버전에 'OpenSolaris'를 선택한다.

메모리의 사이즈를 변경한다. 메모리의 사이즈는 클수록 좋다. 오픈 솔라리스를 위해서는 1024MB 정도를 권한다.

가상 머신에서 사용할 하드디스크를 생성한다. VirtualBox에서 권장하는 오픈 솔라리스를 위한 하드디스크의 크기는 16GB이지만 간단히 사용할 목적이라면 8GB 정도만 할당해도 좋다. 실제로는 4GB 정도면 최소한의 설치가 가능하다. 그러나 최소한의 설치는 권하지 않는다. 기존의 가상 하드디스크가 없으므로 '새로 만들기'를 클릭하여 새 가상 디스크 생성 마법사를 실행시킨다.

새 가상 디스크 생성 마법사가 실행되면 '다음'을 클릭한다.

가상 하드디스크 이미지의 종류를 선택한다. '고정 크기 저장소'는 지정한 하드디스크 용량만큼 미리 할당해 놓는 옵션이다. '동적 확장 저장소'는 게스트 PC의 운영체제에서 사용하는 용량만큼만 할당하고 이후에 유동적으로 할당한다. '고정 크기 저장소'를 선택하여 지정한 하드디스크 용량만큼 미리 할당할 것을 권한다.

가상 하드디스크의 위치는 디폴트 값을 사용하고 용량은 8.00GB만 할당하였다.

설정을 확인하고 '완료'를 클릭한다.

'고정 크기 저장소'를 선택하면 자신의 하드디스크에서 게스트 PC의 하드디스크를 위한 크기인 8GB의 용량을 미리 할당해야 하기 때문에 시간이 걸린다.

가상 하드디스크를 모두 할당하여 가상 하드디스크의 생성이 끝나면 '다음'을 클릭한다.

마지막으로 설정을 다시 확인하고 '완료'를 클릭한다.

가상 머신이 생성되었다. 이제 새로운 운영체제를 설치할 수 있는 PC 한 대가 자신의 컴퓨터 내에 가상으로 하나 더 생긴 것이다. 그래서 이를 가상 머신 혹은 가상 컴퓨터라고 부른다. 가상으로 존재하는 컴퓨터지만 실제 컴퓨터의 역할과 크게 다르지 않다. 위에서 가상 머신의 디바이스 등 여러가지 컴퓨터 사양에 대해서 확인할 수 있다.

오픈 솔라리스를 설치하기 위해 오픈 솔라리스 설치 CD를 가상 머신에 인식시켜야 한다. '설정'을 클릭하거나 [머신] - [설정]을 클릭한다.

가상 머신 설정 창이 나타난다.

왼쪽 창에서 CD/DVD-ROM을 선택한다. 실제 설치 CD인 오픈 솔라리스 LIVE CD를 사용할 수도 있고 iso 이미지 파일을 사용할 수도 있다.

오픈 솔라리스 LIVE CD를 갖고 있으면 컴퓨터의 CD-ROM 드라이브에 CD를 넣고 오른쪽 창에서 'CD/DVD 드라이브 마운트'를 체크하고 호스트 CD/DVD 드라이브를 선택하여 CD-ROM 드라이브인 E 드라이브로 변경한다. 컴퓨터마다 CD-ROM 드라이브의 드라이브 문자가 다를 수 있다. 자신의 컴퓨터에 맞게 선택한다. CD-ROM 드라이브가 두 개라면 설치 CD를 넣은 드라이브를 정확하게 선택한다.

iso 이미지 파일을 사용하려면 오른쪽 창에서 'CD/DVD 드라이브 마운트'가 체크된 상태에서 'ISO 이미지 파일'을 선택하고 오른쪽에 폴더 아이콘을 클릭하여 iso 이미지 파일이 위치한 폴더를 찾아 iso 이미지 파일을 지정한다.

모두 끝나면 '확인' 클릭한다.

오픈 솔라리스를 설치하기 위한 가상 머신의 생성과 설정이 모두 끝났다.

이제 가상 머신을 켜고 오픈 솔라리스를 설치하면 된다.

VirtualBox 가상 머신에 오픈 솔라리스를 설치하는 방법과 VMware 가상 머신에 오픈 솔라리스를 설치하는 방법은 크게 다르지 않다. VMware 가상 머신에 오픈 솔라리스 설치하기를 참고해서 VirtualBox에 오픈 솔라리스를 설치한다.

(참고: http://coronekorea.blogspot.com/2009/02/3_11.html)

VMware 가상 머신에 오픈 솔라리스 설치하기

2009-01-31T00:00:00.000-08:00

VMware 가상 머신에 오픈 솔라리스를 설치한다.

VMware Workstation에 오픈 솔라리스 LIVE CD를 인식시킨 후, 툴바의 '▶' 버튼을 클릭하거나 [VM] - [Power] - [Power On]을 클릭하면 가상 머신이 부팅된다.

파란 바탕화면은 가상 머신의 모니터 화면이다. 모니터 화면을 클릭하면 마우스와 키보드의 제어권을 게스트 PC로 넘긴다. 그래서 마우스와 키보드로 입력하는 데이터는 모두 게스트 PC에 전달되고 호스트 PC에는 입력이 되지 않는다. 마우스 포인터도 게스트 PC의 모니터 화면으로 넘어가며 호스트 PC로 나올 수 없다.
(게스트 PC로 들어간 마우스 포인터를 호스트 PC로 나오게 하려면 [Ctrl] + [Alt]를 동시에 누른다.)

파란 바탕화면의 모니터 화면을 클릭하여 제어권을 게스트 PC로 넘긴 후 'OpenSolaris 2008.05'를 선택한다. 디폴트 값으로 선택되어 있으므로 [Enter]만 누르면 된다.

키보드 레이아웃을 선택한다. 대부분이 US-English 키보드를 사용하므로 기본값인 41을 입력하고 [Enter]를 누른다.

사용할 데스크탑 언어를 선택한다. 여기서는 한국어인 8을 입력하고 [Enter]를 누른다. 데스크탑에서 사용할 언어이므로 원한다면 영어나 일본어를 선택해도 좋다.

키보드 레이아웃과 사용 언어만 선택하면 바로 GUI 화면으로 부팅이 된다.

그러나 아직 하드디스크에 오픈 솔라리스가 설치된 것은 아니다. 이것이 오픈 솔라리스 설치 화면이다. 여기서 OpenSolaris License도 볼 수 있다. 바탕 화면에 있는 'OpenSolaris 설치' 아이콘을 더블 클릭하여 실행한다.

(설치 화면이 잘 보이지 않으면 [Ctrl] + [Alt] + [Enter]를 동시에 눌러 전체 화면으로 전환하거나 바탕화면을 마우스 오른쪽 버튼으로 클릭하여 '화면 해상도'를 선택하고 해상도를 알맞게 변경한다. 전체 화면에서 호스트 PC로 나오려면 역시 [Ctrl] + [Alt]를 동시에 누른다.)

OpenSolaris 설치 프로그램이 열리면 '다음'을 클릭한다.

하드디스크를 용도에 맞게 적당히 분할할 수 있다. 현재의 하드디스크는 VMware에서 생성했던 8GB 크기의 가상의 하드디스크이다. 하드디스크 분할에 익숙하지 않으면 아무런 변경없이 바로 '다음'을 클릭한다.

지역과 날짜와 시간 등을 설정한다. 지역, 위치, 표준 시간대를 선택하고 날짜와 시간은 자동으로 호스트 PC와 동기화되어 있기 때문에 확인한다.

기본 언어 지원과 로켈 특정 데이터 형식을 설정한다.

시스템 관리자인 root의 암호를 입력한다. root는 오픈 솔라리스에서 시스템 최고 권한의 사용자로써 반드시 필요하다. 일반 사용자 계정을 추가로 만들 수 있지만 설치후에도 추가할 수 있기 때문에 여기서는 생략한다. 시스템의 컴퓨터 이름을 입력한다. 본인이 원하는 이름을 아무 이름이나 지정하면 된다.

마지막으로 설정을 다시 확인하고 '설치'를 클릭한다.

'설치'를 클릭하면 설치가 시작된다.

설치가 끝나면 '재부트'를 클릭하여 시스템을 재부팅시킨다. 재부트를 클릭하면 게스트 PC가 재부팅된다. 물론 호스트 PC는 재부팅되지 않는다.

재부팅하면 CD 부팅때와 마찬가지로 부트로더인 파란 바탕의 GRUB이 나타난다. 현재 하드디스크에 오픈 솔라리스가 설치되었으며 하드디스크의 오픈 솔라리스로 부팅할 수 있다. 이제 설치 CD는 필요하지 않다.
'OpenSolaris 2008.05 snv_86a X86'을 선택한다. 디폴트 값으로 선택되어 있으므로 [Enter]만 누르면 된다.

오픈 솔라리스를 부팅하려면 사용자를 선택해서 부팅해야 한다. '사용자 이름: '에 root라고 입력하고 [Enter]를 누른다.

설치시에 입력한 root의 암호를 정확하게 입력한다.

일반적인 목적으로 오픈 솔라리스를 사용하려면 일반 사용자로 로그인하는 것이 좋다. 일반 사용자로 로그인 할 것을 권하는 경고창이다. 무시하고 '계속'을 클릭한다.

오픈 솔라리스가 성공적으로 부팅되었다.

VMware에서 가상 머신 만들기

2009-01-30T00:00:00.000-08:00

VMware Workstation 다운로드 페이지: http://www.vmware.com/download/ws/

VMware Workstation에서 오픈 솔라리스를 설치하기 위한 가상 머신을 만든다.

VMware Workstation을 처음 설치하면 아래와 같은 화면이 나타난다. 예제로 VMware Workstation 6.0.0을 사용하였다. 다른 6.x.x 버전이나 5.x.x 버전에서도 크게 다르지 않다.

위에서 'New Virtual Machine' 버튼을 클릭하거나 [File] - [New] - [Virtual Machine]을 클릭하여 가상 머신 마법사를 실행시킨다.

가상 머신 마법사가 실행되면 '다음'을 클릭한다.

'Typical'은 기본 설정이고 'Custom'은 사용자 정의 설정이다. 일단은 기본 설정인 'Typical'을 선택한다.

설치할 운영체제를 선택한다. 오픈 솔라리스를 설치할 것이므로 'Sun Solaris'를 선택한다. Version에서 'Open Solaris'는 아직 지원하지 않기 때문에 대신 'Solaris 10'을 선택한다.

Virtual machine name은 가상 머신의 관리 및 설정을 위한 이름이다. 본인이 원하는 이름을 아무 이름이나 지정하면 된다. 설치할 운영체제를 잘 나타내는 이름으로 정하는 것이 좋다.
Location은 설치할 운영체제가 위치할 디렉토리이다. 대부분의 운영체제는 용량이 크기 때문에 용량이 충분한 드라이브에 지정하는 것이 좋다. 디렉토리는 본인이 원하는 아무 위치에나 지정하면 된다. 디폴트 값은 "C:\Documents and Settings\HAN\My Documents\My Virtual Machines"이다. 그러나 되도록이면 C 드라이브보다는 D 드라이브로 지정할 것을 권한다. 위에서는 "D:\OS\Open Solaris"로 지정했다.

네트워크 연결을 위해 NAT를 선택한다.
NAT 연결은 새로운 내부 네트워크(서브 네트워크)를 구성하여 게스트 PC를 이 네트워크 내에 연결시킨다. 게스트 PC는 새로 구성한 내부 네트워크의 사설 IP를 사용한다.
Bridged 연결은 호스트 PC가 현재 속해 있는 네트워크에 게스트 PC를 직접 연결한다. 때문에, 게스트 PC는 호스트 PC가 속해 있는 네트워크와 같은 네트워크 주소를 사용한다. 물론 게스트 PC가 인터넷(혹은 외부 네트워크)으로 연결되는 게이트웨이 주소와 호스트 PC가 인터넷으로 연결되는 게이트웨이 주소가 같아야 한다.
Host-only는 외부 네트워크와 연결하지 않을 때 사용하고 Do not use a network connection는 네트워크 연결을 아예 사용하지 않는다. 이 두 옵션은 거의 사용하지 않는다.

가상 머신에서 사용할 하드디스크를 생성한다. 오픈 솔라리스를 위해서는 16GB 정도를 할당하는 것이 좋다. 그러나 간단히 사용할 목적이라면 8GB정도만 할당해도 좋다. 실제로는 4GB 정도면 최소한의 설치가 가능하다. 그러나 최소한의 설치는 권하지 않는다. 위에서는 8.0GB만 할당하였다.
'Allocate all disk space now'는 지정한 하드디스크 용량만큼 미리 할당해 놓는 옵션이다. 선택하지 않으면 게스트 PC의 운영체제에서 사용하는 용량만큼만 할당하고 이후에 유동적으로 할당한다. 이 옵션을 사용하여 지정한 하드디스크 용량만큼 미리 할당할 것을 권한다.
'Split disk into 2GB files'는 하드디스크 파일을 2GB 단위로 나눠서 할당한다. 물론 게스트 PC에서는 이를 알 수 없다. 2GB 단위로 나뉘어져 있다해도 게스트 PC에서는 8GB의 하드디스크로 인식한다. 이 옵션은 호스트 PC인 Windows가 NTFS가 아닌 FAT32를 사용할 경우 4GB 이상의 파일을 인식하지 못하는 문제를 해결하기 위하여 유용하다. 혹은 가상 머신을 DVD에 저장하고자 할 때도 유용하다. 그러나 이외의 경우에는 굳이 이 옵션을 사용할 필요는 없다. 위에서는 이 옵션을 사용하지 않는다.

'Allocate all disk space now' 옵션을 선택하면 자신의 하드디스크에서 게스트 PC의 하드디스크를 위한 용량인 8GB의 용량을 미리 할당해야 하기 때문에 시간이 걸린다.

하드디스크까지 모두 할당이 되면 가상 머신 생성이 끝난다. 이제 새로운 운영체제를 설치할 수 있는 PC 한 대가 자신의 컴퓨터 내에 가상으로 하나 더 생긴 것이다. 그래서 이를 가상 머신 혹은 가상 컴퓨터라고 부른다. 가상으로 존재하는 컴퓨터지만 실제 컴퓨터의 역할과 크게 다르지 않다. 'Close'를 클릭하면 마법사를 종료한다.

'Open Solaris' 탭이 생긴 것을 확인할 수 있다. 디바이스 등의 여러가지 컴퓨터 사양에 대해서도 확인할 수 있다.

[가상 머신 설정하기]
오픈 솔라리스를 설치하기 전에 최적의 상태를 위해 설정을 조금 변경한다.

'Edit virtual machine settings'를 클릭하거나 [VM] - [Settings]를 클릭하면 아래와 같이 Virtual Machine Settings 창이 나타난다.

Virtual Machine Settings 창이 나타난다.

왼쪽 창에서 Memory를 선택하고 오른쪽 창에서 메모리의 사이즈를 변경한다. 메모리의 사이즈는 클수록 좋다. 오픈 솔라리스를 위해서는 1024MB 정도를 권한다.

플로피 디스크는 필요없기 때문에 제거한다. Floppy를 선택하고 아래의 'Remove'를 클릭한다.

호스트 PC인 자신의 컴퓨터의 CPU가 2개라면 가상 머신의 성능 향상을 위해 가상 머신에서 2개의 CPU를 모두 사용하도록 할 수도 있다. Processors를 선택하고 Two로 변경한다. 이 옵션은 반드시 필요하지는 않다.

오픈 솔라리스 설치를 위해 설치 CD를 인식시킨다. 실제 설치 CD인 오픈 솔라리스 LIVE CD를 사용할 수도 있고 iso 이미지 파일을 사용할 수도 있다.

오픈 솔라리스 LIVE CD를 갖고 있으면 컴퓨터의 CD-ROM 드라이브에 CD를 넣고 왼쪽 창에서 CD-ROM을 선택하고 오른쪽 창에서 Use physical drive를 선택하여 CD-ROM 드라이브인 E 드라이브로 변경한다. 컴퓨터마다 CD-ROM 드라이브의 드라이브 문자가 다를 수 있다. 자신의 컴퓨터에 맞게 선택한다. CD-ROM 드라이브가 두 개라면 설치 CD를 넣은 드라이브를 정확하게 선택한다.

iso 이미지 파일을 사용하려면 왼쪽 창에서는 CD-ROM을 선택하고 오른쪽 창에서는 Use ISO image를 선택하고 'Browse'를 클릭하여 iso 이미지 파일이 위치한 폴더를 찾아 iso 이미지 파일을 지정한다.

설정이 모두 끝나면 'OK' 버튼을 클릭한다.

오픈 솔라리스를 설치하기 위한 가상 머신의 생성과 설정이 모두 끝났다.
이제 가상 머신을 켜고 오픈 솔라리스를 설치하면 된다.

(용어 정리)
호스트 PC: 실제 컴퓨터. 위의 예제에서는 Windows XP이다.
게스트 PC: 호스트 PC내에 생성되는 가상의 컴퓨터. 위의 예제에서는 오픈 솔라리스이다.

오픈 솔라리스 Open Solaris

2009-01-10T00:00:00.000-08:00

꿈의 OS - 오픈 솔라리스
지.구.상.에.서. 가.장. 진.보.된. 운.영.체.제.

오픈 솔라리스는 썬 마이크로시스템즈에서 개발된 유닉스 운영체제인 솔라리스를 오픈 솔라리스 프로젝트 커뮤니티에서 소스코드를 공개하여 배포되는 운영체제이다.

다운로드 페이지: http://www.opensolaris.org/os/downloads/
최신버전 (2008.11): http://dlc.sun.com/osol/opensolaris/2008/11/osol-0811.iso