새우의 세상사

원문 링크 : Ubuntu 핵심개발자인 Jeff Waugh에게 듣는「설치가이드」


'Ubuntu Linux' 핵심개발자인 Jeff Waugh에게 듣는「설치가이드」

사용자 삽입 이미지

Jeff Waugh

Jaqui Greenlees ( TechRepublic )

기고가 자키 그린리스는 우분투(Ubuntu) 리눅스를 설치하는데 몇 가지 문제가 있었다. 그래서 그에 대한 답을 얻기 위해 개발자 중 한 사람과 이야기해 보기로 했다.

최근 우분투 리눅스를 살펴보기로 마음을 먹은 나는 디폴트로 세팅된 패키지와 구성으로 설치하는 과정 중에 나타나는 몇 가지 문제점을 발견하였다. 그래서 우분투 리눅스의 대표에게 구성 및 디폴트 패키지와 관련된 문제들을 이메일로 물어보기로 결심했다.

아래에 제프 워와 한 이메일 인터뷰가 나타나있다. 제프 워는 우분투리눅스(UbuntuLinux)의 핵심 개발팀의 한 멤버이다. 받은 이메일의 다른 부분은 편집하지 않았고 레이아웃만 조금 고쳤다. 관련된 섹션은 함께 묶었고, 읽기 편하게 하기 위해 이메일 클라이언트가 추가하는 형식을 제거하였다. 이 형식으로 주고 받은 이메일의 길이가 미국 편지 사이즈 기준으로 여섯 페이지에 달했다. 이메일에 언급된 부분들에 대한 참조를 위해 필요한 URL도 덧붙여 놓았다.
설치 문제
설치 과정 중에 겪은 문제들은 꽤 간단해 보인다. 진짜 문제는 내가 실제로 우분투 리눅스를 설치할 때 따라야 하는 순서들에 있었다.

브리지 뱃져(Breezy Badger)판 우분투 리눅스에 내장된 파티셔닝 소프트웨어는 건드리지 않아야 하는 파티션을 무시하지 못했다. 나는 컴퓨터에 여러 리눅스 배포판을 설치해 멀티 부팅 시스템을 가지고 있는데, 우분투에 들어있는 소프트웨어 버전은 메인 하드 드라이브에 데비안이 생성한 파티션을 읽지 못했다. 결국, 우분투 리눅스를 설치하기 위해서 시스템의 메인 하드 드라이브를 삭제해야만 했다.

우분투 리눅스가 빛 좋은 개살구처럼 보이고, 그들의 개발자 팀에 의해 내려진 결정들이 오히려 내가 우분투가 기능적인 면이 심각하게 빠져 있다는 느낌을 계속해서 가지게 했다. 그들은 하드웨어 지원을 넓히려고 노력했지만, 아직도 그러한 소프트웨어들은 특히나 지원하기로 되어 있는 하드웨어와도 여전히 충돌을 일으키고 있다. 랩톱 유틸리티 패키지는 랩톱 컴퓨터의 델 배터리를 훼손시킨다. 이 소프트웨어는 델(Dell) 랩톱과 충돌을 일으키지만 랩톱 유틸리티들은 반드시 필요하기 때문에, 배터리를 사용하거나 리눅스의 다른 배포판을 사용할 때 랩톱 성능이 75% 정도 감소하는 것을 받아들여야만 한다. 데스크톱 시스템에 랩톱 툴을 요구하는 것은 전혀 이치에 맞지 않는다.

데스크톱 시스템에 존재하지 않는 하드웨어 지원을 요구하는 로직 때문에 나는 설치에 실패하였다. 따라서 하드웨어 지원이 선택적인 것이 되어야 한다. 하드웨어에 대한 지원 요구 이면에 있는 실제적 문제는, 심지어 실제로 그러한 지원이 존재하지 않는 경우에도 아무런 이유없이 시스템의 자원을 낭비한다는데 있다. 어떤 패키지에 의해 라이브러리가 요구되면, 라이브러리는 램을 할당받아야 하며 패키지를 실행하면 그 라이브러리가 램에 로드된다.

어떤 파티션이 사용되지 않았다면, 그것은 스왑 파티션으로 사용될 수도 있지만, 할당된 램은 애플리케이션이 끝날 때까지 해제되지 않고, 모든 마우스 클릭이 라이브러리에 제공되는 기능을 호출하는지를 확인하게 된다. 이때 존재하지도 않는 하드웨어를 지원하는데 CPU 타임이 낭비되게 된다. 만약 당신이 그 라이브러리가 제공하는 함수를, 그것이 지원하는 하드웨어 없이 호출했다면, 당신은 에러 메시지만을 보게 될 것이다.

정말 말이 안 되는 문제는 설치된 모든 패키지를 업데이트 해야 하는 요구조건이다. 심지어 그 패키지들 중 하나가 시스템이 허락하기만 한다면 곧 삭제될 것이라 하더라도 일단은 업데이트를 먼저 해야 한다.

내가 두 번째로 최악이었던 브라우저를 지우려고 했을 때, 우분투 리눅스를 망가뜨리지 않고서는 못 지운다는 것을 알고는 경악을 금치 못했던 상황을 생각해 보라. 나는 파이어폭스(Firefox)를 사용하지 않는다. 왜냐하면 그 유저 인터페이스를 싫어했기 때문에 만약 인터넷 익스플로러가 필요하면, 크로스오버 오피스(Crossover Office)나 와인(WIne)을 통해 설치하려고 할 것이다. 파이어폭스는 인터넷 익스플로러처럼 보이고, 느껴지게 하려고 고안되었지만, 그것은 내가 그것을 사용하지 않기에 충분할 정도로 나빴다.

나는 개인적으로 우분투의 기본 GUI를 사용하지 않을 것이다. 왜냐하면 그놈(GNOME)은 MS 서버와 연결되어 있지 않을 때 올바로 동작하지 않기 때문이다. 리눅스만 사용하는 나의 상황에서 이것은 앞서 말한 랩톱 유틸리티들이나 블루투스 유틸리티들과 같은 것을 사용하는 것과 마찬가지로, 분명한 자원의 낭비이다.
제프워가 말하는 우분투 리눅스 설치의 주요 이슈와 특징

시냅틱(Synaptic)은 루트 패스워드를 받아들이지 않을 것이다. 대체 시작할 수 없다면, 좋은 GUI가 무슨 소용이란 말인가?
우분투에서, 우리는 루트 계정을 사용하지 못하도록 했다. 그리고 대신에 완전한 sudo 기능을 가지는 첫 번째 유저 계정을 제공한다. 따라서 당신은 관리자 도구를 사용하려고 할 때 단지 당신의 계정 패스워드를 입력하기만 하면 된다. 당신은 설치프로그램이 루트 패스워드를 물어보지도 않는다는 것을 알게 될 것이다. :-)

설치프로그램은 관리자 패스워드를 물어보았고 나는 4글자의 패스워드를 입력했었다. 그리고 2개의 다른 패스워드를 입력했는데, 하나는 루트를 위한 것이었고, 하나는 비 관리자 유저를 위한 것이었다.
혹시 "전문가용"을 설치하였나? 그것은 추천할 만하지 못하다. 왜냐하면 그것은 시간 낭비이기 때문이다.
아니다. 단지 설치 프로그램을 실행시켰을 뿐이다.
만약 단순히 설치 프로그램을 실행시켰다면, 당신에게 루트 패스워드를 물어보는 일은 없었을 것이다.

Bluez 유틸리티들이 요구되는가? 왜 요구되는가? 나는 블루투스 관련 장치는 아무것도 가지고 있지 않고, 따라서 그것은 순전히 시스템 자원의 낭비이다.
우리는 많은 컴퓨터 하드웨어를 지원하고 그것들을 사용할 수 있도록 도구도 제공한다. 만약 블루투스 관련 하드웨어가 없다면, 어떠한 자원도 낭비되지 않을 것이다. 왜냐하면 그것들이 사용되지 않기 때문이다(물론, 디스크 상에서 공간을 차지하기는 하겠지만 그다지 많은 양이 아니다.).

다시 말하지만, 우리는 많은 컴퓨터 하드웨어를 지원한다. 이것은 정말, 아주 정말 작은 패키지이다. 심지어 우리가 포함하는 그 어떤 랩톱 하드웨어 지원 유틸리티들보다 작다. 따라서 우리는 이것을 "멍청한" 행동으로 생각하지 않는다. 만약 당신이 그 패키지에서 필요로 하는 하드웨어가 없다면 그것은 사용되지 않을 것이다.

하지만 그렇다면 그것은 의존적인 것이 되어서는 안 된다. 설치하는 것이 추천되는 것으로 되어야지, 반드시 설치해야 할 패키지여서는 안 된다. 그것을 설치하라고 요구하거나 설치하는 데 실패하는 배포판은 거의 없다. 그리고 그 패키지를 사용하는 하드웨어가 없을 때, 그 패키지를 지우는 것이 가능해야만 한다. 랩톱 유틸리티들이 설치되도록 요구함으로써 당신은 유저들이 너무 무지해서 그들의 하드웨어들이 무엇인지 알 리 없다고 말하는 격이다.
아니다. 우리는 유저들이 어리석다고 말하는 것이 아니다. 우리는 유저들이 많은 자세한 사항들에 대해서는 신경 쓰지 않는 것에 대해 이해하고 있다. 그들은 단지 동작하기만을 바라는 것이다. 우분투가 「유일한」 하나의 CD에 담겨 있는 것을 기억하기 바란다. 우리는 애플이나 MS, 그리고 다른 리눅스 배포판에 비해 그 용량을 최소로, 반면 놀라울 정도의 하드웨어 지원, 그리고 많은 컴퓨터 이외의 경험을 제공하려고 노력하고 있다.

또한, 우리는 기본 데스크톱 프로그램 전체를 CD 한 장에 담았다. 다른 대부분의 리눅스 배포판은 3장 혹은 그 이상이다. 우리는 사용의 용이성과 광범위한 하드웨어 지원 그리고 쓸데없는 기능들을 최소화시키는 것 사이에서 균형을 잘 맞추었다고 본다.

Bluez 패키지는 블루투스 정치에 연결하기 위한 것이 아니라면, 다른 어떤 소프트웨어에서도 필요하지 않다.
사실, 블루투스 서브 시스템과의 인터페이스에 사용되는 라이브러리들은 하드웨어의 통합성을 제공하기 위해 수많은 애플리케이션이 사용한다. 이것의 좋은 예로, nautilus-sendto가 있는데, 이 작은 애플리케이션이 이메일, 인스턴트 메시지, 블루투스 등등을 이용하여 파일 매니저로 부터 파일을 보낼 수 있도록 한다.

아니? 도움말 시스템과 우분투 데스크톱은 bluez 유틸리티들을 필수로 해놓았으며 그것은 지워지지 않는다. 하드웨어를 지원한다는 것은 좋다. 하지만 전체 GUI가 필수로 해놓는 꼭 필요한 라이브러리는 아니다.
당신은 라이브러리에 의존할 수 없다. 만약 그렇게 한다면, 스택에서 마술처럼 꺼낼 수 있다. 만약 당신이 레퍼런스를 알고 있다면, 이것은 마치 젠가를 하는 것과 같다(젠가는 나무 조각들로 이루어진 큰 탑에서 조각들을 하나씩 꺼내다가 무너지면 지는 게임이다.).

파이어폭스는 필수 요구사항인가? 나는 파이어폭스를 싫어한다. 그리고 앞으로도 사용하지 않을 것이다. 따라서 당연히 그것을 설치하려고 하지 않을 것이다.
우리는 되도록이면 많은 유저들에게 유용할 수 있는 최소한의 소프트웨어들을 설치한다. 파이어폭스는 브라우저 기술에서 표준이고, 그래서 설치하게 된 것이다. 많은 기술적인 이유들 때문에, 그것은 삭제될 수 없다. 왜냐하면 시스템에 있는 다른 소프트웨어들이 파이어폭스의 렌더링 엔진을 사용하고 브라우저 자체로부터 아직까지 분리되지 못했다.

참고로 말하자면, 나는 보통 직접 리눅스시스템을 구축하여 사용한다. 그리고 파이어폭스는 당신이 그렇다고 말하는 소프트웨어에 필요하지 않다.
렌더링 엔진은 우리의 시스템에 있는 도움말 브라우저나 다른 소프트웨어들이 사용한다.

게코(Gecko)의 렌더링 엔진은 따로는 사용할 수 없다. 언제부터 그랬나? 그것은 처음부터 소스섹션과는 분리되어 있었다.
분리된 라이브러리 인터페이스로서는 사용할 수 없다. XULrunner가 Mozilla.org에 올라갔을 때, 우리는 그것을 사용하기 위해 렌더링 엔진을 사용하는 모든 소프트웨어를 다시 확인할 가능성이 크다. 이때가 되면 파이어폭스는 더 이상 필요조건이 되지 않을 것이다.

하지만 게코는 파이어폭스에만 국한되지 않고 소스에서 독립적인 아카이브이다.
다시 말하지만, XULrunner가 배포될 때까지, 렌더링 엔진은 분리된 라이브러리 인터페이스에서 사용될 수 없다(심지어 XULrunner가 배포 된다고 하더라도, 게코를 사용하지는 않을 것이다. 전체가 XUL 스택을 이용할 것이다.).

나는 파이어폭스가 완전한 기준이라고 생각하지 않는다. 차라리 시몽키(Seamonkey)가 기준이라고 생각한다(시몽키는 바로 그 정확하게 일치하는 렌더링 엔진을 사용하고 보다 강력한 인터페이스와 많은 도구를 제공한다. 이것은 모질라의 새로운 버전이다.).
그것은 당신의 기호이다. 하지만, 파이어폭스가 시몽키보다 많은 시장을 점유한 데에는 큰 이유가 있다. 내가 보기에는 당신이 당신의 기술을 가지고 이리저리 만드는 것을 좋아하는 것처럼 보인다. 대부분의 컴퓨터를 사용하는 인구는 당신이나 혹은 나와 같지 않다는 것을 유념하기 바란다.
모질라의 사이트에 따르면, XULrunner가 사용 가능하다고 하는데..
아직 안정적이지가 않다. 우리는 우분투 6.10 버전에서나 채택하게 될 것 같다.

랩톱 유틸리티들이 데스크톱 시스템에서 필요조건인가? 이것이야 말고 정말 멍청한 것 아닌가?
또 말하지만 우리는 많은 하드웨어를 지원한다. 이것은 아주 정말 작은 패키지로 다른 어떤 랩톱 하드웨어 지원 유틸리티들보다도 작은 크기이다. 따라서 우리는 그것을 "완전히 멍청한 짓"으로 여기지 않는다. 그 패키지를 필요로 하는 하드웨어를 당신이 가지고 있지 않다면 그 패키지는 사용되지 않을 것이다.

콘솔 상에서 vim을 가지고 작업하는 중에 바깥 시스템 파일을 수정하는 방법이 없는데 이것은 마치 루트 계정이 GUI에서 완전히 막혀 있는 것처럼 보인다.
당신은 sudo 뿐 아니라 그래픽 애플리케이션이 필요하면 그것을 사용할 수 있다. 하지만 우리는 그것을 권장하지 않는다. 사용 가능한 관리자 도구가 많이 있다. 우리는 우리의 유저들에게 시스템 파일을 편집하도록 강요하는 데에는 전혀 관심이 없다.

sudo 단일 유저가 모든 것을 다 하기 때문에 이것은 심각하게 흠이 있는 보안 모델이다. 나는 항상 관리자 목적으로 루트 계정을 사용한다.
유감스럽게도, 그것은 흠이 있는 보안 모델이 아니다. 우리는 보안 문제에 매우 주의를 기울였다. 그리고 이것은 대형 서버 배포와 단계적 권한이 필요한 접근법에 알맞은 종류의 구성이다. 이것이 데스크톱 시스템의 요구조건들에 매우 깔끔하게 들어 맞는다는 것을 인정할 것이다. 루트에 관한 모든 개념이 다른 배포판을 사용하는 유저들에게 짐을 준다는 것은 조금 실망스럽다. 당신은 맥 OS X가 우분투와 매우 비슷한 접근법을 사용하는 것을 알게 될 것이다.

그러나 시스템 관리자 패스워드를 GUI로 되어 있는 시스템 관리자 도구에 입력할 방법이 없다. 나는 관리자와 같은 보통 유저들이 좋은 보안 모델만큼 좋은 능력을 가진다는 말에는 반대한다. 이 방법 때문에 윈도우 컴퓨터에 불량 하드웨어와 소프트웨어들이 판을 치고 있기 때문이다.
우분투가 그렇게 동작하지는 않는다. 유저는 그들이 관리자 작업을 수행할 때에는 반드시 가지고 있어야 하는 sudo 권리를 가지고 있는 상황에서만 관리자이다. 유저는 일반적인 사용에 있어서는 불필요할 정도로 많은 특권을 가지지 않는다. 루트 패스워드를 가지고 입력해야 하는 패스워드가 다르게 되는 것이 성격적으로 다른 것이 아니다. 우리는 이것에 대해 오랫동안 힘들게 생각해 보았다. 그리고 우리는 보안 문제에 대해서 매우 보수적인 접근법을 택했다. 궁극적으로, 이것이 유닉스 시스템이 통상적으로 동작하기에 최선이다. 전문 시스템 관리자들 역시 같은 것을 말할 것이다.

"유일한 관리자가 모든 것을 하는 것"이 모든 윈도우 컴퓨터가 관리자 모드로 돌아가는지에 대한 이유이다. MS는 아직 좋은 멀티유저 OS를 만들지 못했다. 당신은 지금 이러한 보안 모델을 사용함으로써 리눅스를 MS의 하자 있는 멀티 유저 모델을 따라가고 있는 꼴이다.
왜 당신이 말한 것이 그러한 경우에 해당되지 않는지 앞뒤 글을 읽어보기 바란다. 시행중인 안 좋은 아이디어들에 대한 예를 보고 싶다면 린스파이어(Linspire)를 보기 바란다. 린스파이어에서는, 사용자 계정이 옵션이다. 그리고 디폴트의 단일 유저 구성에서 모든 것이 루트로 구동된다. 이것이 바로 윈도우가 망쳤던 "모든 사람이 관리자 모드로 로그인 하는 것"의 예이다.

루트 계정은 사용되기 위해서 있다. 따라서 sudo는 보안 측면에서 위험을 안고 있다. 세큐니아(Secunia)의 고문단은 컴퓨터 종료 시에 sudo가 완벽하게 해제되지 않아서 시스템이 공격당하기 쉽게 된다고 했다. 이것은 세큐니아가 우분투에 대해 실제로 보고했던 것이다. 나는 여전히 sudo를 루트 계정 대신에 사용하는 것이 보다 안전하다는 데에는 동의할 수 없다.
유감스럽다. 하지만, 나는 당신이 그것을 사실인 것처럼 말할 만큼의 지식적 깊이가 있다고는 생각하지 않는다. 물론 당신의 의견은 당신에게는 받아들여지겠지만.

나는 su를 한 명의 유저(나의 계정)만 사용할 수 있도록 해 놓았다. 그런데 나 조차도 그것을 거의 사용하지 않고, 다른 유저들은 su를 사용하도록 허용되지 않는다. 적어도 나에게는 시스템 관리자는 일반적인 사용으로부터 철저히 독립되어 있다.
그 말은 sudo에도 똑같이, 그러나 매우 작은 수준으로 적용된다. 이것이 바로 왜, 안전한 단계적 작업 기반 권한에 관심 있어 하는 시스템 관리자가 그것을 선택하는지에 대한 이유이다. 그 말은 일반적으로 틀린 말이다. 그리고 우리가 미리 구현해 둔 다른 규칙들 때문에 우분투에서 역시 완전히 틀린 말이다. 예를 들어 tty당 타임아웃이 그렇다. sudo는 우리의 프로그램에서 독립적인 루트 계정과 패스워드를 가지는 것에 비해 보안 위험이 많지 않다. 그리고 사실 일반적인 경우에는 위험을 감소시켜 준다. 우리는 윔(whim)에서는 아직 이것을 하지 않았다.

다른 패키지와 작업하기 전에 강제 업데이트를 해야 한다? 당신은 MS 소속인가? 패키지를 가지고 무슨 일을 하기 위해서는 반드시 업데이트를 해야 하는가? 일정한 업데이트 알림이 항상 있는가? 이것은 리눅스만 사용하는 지금, 내가 전혀 생각하지 않는 MS적인 것이다.
나는 당신이 무엇에 대해서 언급하고 있는지 확실치 않지만, 만약 그것이 설치 후 업데이트에 관한 것이라면, 가장 최신 버전의 보안 프로그램과 버그를 고친 것을 사용하도록 하는 것이 우리의 프로그램을 사용하는 유저에 대한 예의라고 생각한다. 우리는 또한 유저들이 언제 업데이트가 가능한지를 알려주고 있다. 왜냐하면, 유저들이 그들의 시스템을 항상 최신의 것으로 유지하는데 가장 중요한 역할을 맡고 있고, 무엇을 하고 있는지 가장 잘 이해하고 있기 때문이다. 유저가 모르게 그것을 하는 것은 좋지 않을 수 있다. 나는 왜 당신이 이것을 MS적인 행동이라고 말하는지 모르겠다. 이것은 현대의 OS 보안에서 매우 중요한 기능이다.

내가 몇 개의 소프트웨어를 더 설치하고 싶었다. 업데이트를 하라고 해서 업데이트를 하려고 했지만, 업데이트도 하기 전에 설치해야 하는 소프트웨어가 너무 많아서 짜증이 났다. 왜 사람들이 모든 업데이트 프로세스를 거치도록 강요하는가? 단지, 보다 많은 패키지를 추가하기 위해서? 이 두 가지 방법 다 시간을 절약하지는 않는다. 필요치 않은 패키지를 삭제할 수 있도록 하려고? 나는 내가 지우고자 하는 프로그램을 지우기 바로 전에 업데이트를 할 것이다. 이것이 시간의 낭비가 아니고 무엇인가?
대퍼(Dapper)가 배포되었을 때를 생각해 보라. 나는 그것이 당신이 가지고 있는 문제를 해결해 줄 수 있다고 생각한다. 이 문제가 그리 큰 것이 아니라 할지라도, 만약 긴 안목에서 보았을 때, 당신이 리눅스를 데스크톱에서 사용하는 것 자체를 싫어하게 될지도 모르기 때문에, 당신 입장에서는 이 문제가 실상 작다고만 볼 수는 없을지도 모른다.

알림 : 업데이트를 알리는 팝업 창은 짜증 나는 것이다. 그리고 MS는 그런 짜증나게 하는 일을 가장 잘한다. 우분투는 이런 MS의 방법을 고스란히 이어받아 매 30초 마다 업데이트가 시작될 때까지 팝업창이 나타나게 한다. 매우 MS스러운 일이다.

사용할만한 어떤 소프트웨어도 당신이 윈도우 서버에 연결되어 있지 않다면, libsmb를 요구하지 않는다. 어떤 좋은 리눅스 데스크톱 애플리케이션도 설치될 때, 윈도우 서버 연결을 요구하지 않는다. 그래서 나는 GNOME을 설치하지 않았다. GNOME은 이런 리눅스 데스크톱을 위해 smb 스택을 요구할 만큼 어리석다.
모든 대형 리눅스 데스크톱 시스템은 윈도우와 삼바(Samba) 파일공유를 사용한 기능을 제공한다. 우리는 그것이 우리의 많은 유저들이 가장 많이 사용하는 것이라고 생각하기 때문에 그들이 일상의 작업에 완전한 리눅스 기반 네트워크를 사용하건, 윈도우 컴퓨터를 사용하건 간에 그것을 지원한다.

여전히 당신은 90%는 쓸데없는 소프트웨어의 강제적 설치가 옳다고 주장하고 있는가? 그것은 시스템에 쓸모없는 것이다. 랩톱 유틸리티, bluez-utils, 삼바 서버 스택은 당신이 랩톱을 쓰거나, 블루투스 장치를 가지고 있거나, 혹은 윈도우 웍스테이션을 가지고 서버를 구동시키지 않는다면 모두 쓸데없는 것이다. 삼바 서버 스택이 gnome의 잘못이지, 우분투의 잘못이 아니라는 것은 알고 있다. 나는 개념에 대해서도 비판하고 있는 것이다.
우리는 삼바 서버를 올리지 않았다. 그리고 GNOME은 그것을 필요로 하지 않는다. 만약 GNOME에 대해서 이야기하고 싶다면, 나에게 알려주기 바란다. 나는 지난 5년간 관리프로그램을 제작해왔다.

나는 그것이 시스템에 있어 쓸모없는 것이라는 의견에 동의하지 않는다. 그것은 매우 작은 공간만 차지하고, 대부분의 유저들은 그것을 신경 쓰지 않는다. 그것이 어떤 속도도 느려지게 하지 않고, 누군가의 작업을 방해하지도 않는다. 당신이 매우 세세한 것이 관심이 있기 때문에 당신이 눈치를 챈 것뿐이다. 하지만, 나는 당신이 계속해서 그것을 신경 쓸 것이라고는 생각하지 않는다.

그래서 GNOME 애플리케이션이 리눅스만 사용하는 환경에서 필요치 않는 도구들을 사용한다는 뜻인가. 그렇다면 GNOME 자체는 리눅스만 사용하는 환경에서 자원을 낭비하는 도구를 사용한다. 그것들이 애플리케이션의 추가 때문에 더 많은 자원의 낭비를 요한다는 것은 놀라운 일이 아니다.
당신이 개념을 잘못 잡았다고 생각한다. 우선, 우리는 우분투를 리눅스만 사용하는 환경을 위해서 디자인하지 않았다. 또 그러한 환경은 매우 드물기도 하다. 우리는 우리의 유저들이 마주치는 매일의 작업 환경을 위해서 만들었다. 그리고 이것은 각기 다른 시스템의 전체 스택을 공동으로 이용 가능하도록 하는 것이 필요하다는 것을 의미한다. 기술적인 용어로, 만약 당신이 smb 지원을 사용하지 않았을 때, 어떠한 자원도 낭비되지 않는다는 것이다. smb 지원은 사실상 분리된 프로세스 바깥에서 돌아가는 프로그램에 의해 제공된다. 따라서 당신이 그것이 필요 없다면, 실행하지 않으면 되는 것이다.

유감스럽게도, 나는 당신이 이러한 말다툼을 계속하는 것에 관심이 있다면, '자원' 대신에 보다 관련된 용어를 사용하기 시작할 필요가 있다고 생각한다.

미안하다. 어떠한 데스크톱 소프트웨어도 삼바 서버 스택을 사용할 가치가 없다면 필요로 하지 않을 것이다. 왜 데스크톱이 서버가 되어야 하는가?
데스크톱에서 돌아가는 서버 스택은 필요치가 않다.

나는 libsmb의 설명을 다시 읽어보았다. 윈도우 서버에 연결할 수 있게 한다고 내가 처음에 언급했던 것과는 달리 그것은 윈도우 데스크톱을 연결할 수 있도록 하는 서버 스택이다.
아니다. Libsmb 클라이언트는 CIFS/SMB 프로토콜을 사용하기 위한 또 다른 소프트웨어에 대한 인터페이스이다. 그것은 실제로 삼바 서버가 로컬 컴퓨터에서 돌아가는 것을 요구하지 않는다. 삼바 패키지는 우리의 데스크톱 제품의 디폴트 설치 패키지가 아니다.

GNOME과 관련된 나의 문제는 libsmb클라이언트가 아니라 libsmb이다. 이것은 서버 스택이고 분명히 GNOME을 요구한다.
libsmb와 같은 것은 없다. 그리고 다시 말하지만 당신이 언급하고 있는 것은 삼바 데몬이 아니다. 삼바 데몬은 데비안과 우분투를 위한 것으로 삼바 패키지에 들어 있다. 당신이 CIFS/SMB 서비스를 사용하기 위해, GNOME 파일 매니저나 vfs를 통해 삼바 데몬을 구동시킬 필요가 전혀 없다.

왜 패키지가 권고 사항이 아니라 강제사항인가? 만약 그것이 강제 사항이라면, 시스템은 그 패키지들 없이는 제대로 기능 하지 않을 것이다. 이것은 도움말 시스템, 데스크톱이 그러할 것이라는 것을 의미한다.
아니다. 예를 들어보면, 우리가 nautilus-sendto라는 프로그램을 구현했는데, 이것은 매우 작은 크기로, 파일 매니저를 위해 파일을 보내는 기능을 하는 것이다. 이것은 에볼루션(Evolution), GAIM, 그리고 블루투스 장치들과 함께 동작한다. 따라서, 당신은 이메일이나 인스턴트 메시지로 혹은 당신의 전화에 파일들을 보낼 수 있다. 그렇게 하기 위해 블루투스 라이브러리를 사용한다.

만약 당신이 블루투스 라이브러리를 없앤다면, nautilus-sendto는 삭제될 것이다. 이것이 바로 동작하는 방식이다. 블루투스 라이브러리가 사용되거나 메모리에 로드되는 그 시간만이 nautilus-sendto가 호출되는 때다. 그러나 당신이 시스템에 블루투스 하드웨어를 가지고 있으면 부팅될 때 실행되는 매우 낮은 수준으로 블루투스를 지원하는 데몬들도 있다. 따라서 당신이 블루투스 하드웨어를 가지고 있지 않은 상황에서는 이러한 기능을 제공하는 어떠한 자원, 예를 들어 램과 같은 자원도 사용되지 않는다.

우리가 우분투에 소프트웨어 강제사항으로 포함하기는 했지만 사용하지 않는 프로그램들이 많이 있다.

그 말이 바로 우분투가 GNOME을 사용하기 때문에, 세 가지 네트워크 스택이 있다는 것이다. 대부분의 네트워크 카드를 위한 커널 레벨 스택, libsmb 스택 그리고 GUI를 위한 bluez-utils 스택
이것은 대답하기가 힘들다. 왜냐하면, 당신이 전혀 관련 없는 것들까지도 섞어서 말하고 있기 때문이다. 당신이 위에서 언급한 예는 같은 소프트웨어 카테고리에 들지 않는다. 따라서 그 세 가지를 모두 가지는 것이 낭비이고 쓸모없다고 말할 수 없다. 그것들은 모두 매우 다른 기능을 제공하고 있고, 컴퓨터 바깥의 하드웨어 지원과 상호 운영성과 같은 당연한 이유로 디폴트로 설치된다.

내용출처 : ZDNet Korea

신고
Posted by 새우날다 Trackback 0 Comment 0

원문 링크 : 리눅스가 데스크톱에 오르지 못하는 이유


리눅스가 데스크톱에 오르지 못하는 이유

서버 분야에서 리눅스를 비롯한 프리 또는 오픈소스 소프트웨어의 득세는 이미 잘 알려져 있다. 웹 서버, 이메일 서버 등 네트워크 에지에서 그리고 데이터센터에서 그렇다. 그러나 과연 데스크톱에서의 리눅스는 어떨까?

리눅스 데스크톱 패키지는 이제 보다 많은 기능을 담고 있으며 패키지도 더 좋아지고 있다. 현재의 리눅스 데스크톱 패키지의 사양과 가격은 최소한 오픈소스로의 전환을 고려할 만한 가치는 있다.

많은 기업에 있어서 이는 충분한 의미가 있다. MS 윈도우 비스타는 아직 갈 길이 멀고, 윈도우 XP는 최신 서비스 팩을 설치해도 수많은 악성코드의 목표가 되고 있다.

쓸만한 리눅스 패키지는 현재 완전한 사무실용 패키지와 이메일, 캘린더 소프트웨어, 그리고 인스턴트 메시징과 같은 추가 기능도 제공한다. 모든 것은 무료이거나 최악의 경우 가격은 윈도우 XP 정도다.

저항이 가장 큰 사용자 데스크톱

브리스토 카운슬과 같은 대형 사용자들은 윈도우 컴퓨터에 MS 오피스를 대체하기 위해 오픈오피스나 스타오피스와 같은 오픈소스 애플리케이션을 사용한다. 또한 MS IE 대신 파이어폭스를 사용한다. 파리시는 공공 서버를 리눅스로 전환하고 있으며 데스크톱에 파이어폭스와 오픈오피스를 사용하고 있다.

그러나 데스크톱 운영체제를 리눅스로 대체하는데는 보다 높은 저항이 있다. 영국 정부가 지원하는 오픈소스 아카데미는 PC를 씬 클라이언트 솔루션 사용을 위한 터미널로 전환한 입스위치 근처의 오웰 스쿨을 예로 든다. 한편 버밍햄 카운슬은 오픈소스 아카데미와 부수상실이 지원하는 시험판을 운용하고 있다. 이는 리눅스 데스크톱의 유용성을 평가하기 위한 것이다.

비록 버밍햄 카운슬의 IT 관리자인 레스 팀스는 시험 평가가 잘 진행되고 있다고 말했지만 최종 결과는 2006년 2월이 돼야 나올 것이다. 그리고 공공 도서관에 있는 40대의 PC는 리눅스로 대체됐다.

MS 윈도우 vs. 리눅스 운영체제

지디넷의 경험에 바탕한다면 문제는 리눅스 운영체제의 구성요소나 이들의 구성방식에 있지 않다. 우리는 기본적인 사무실 소프트웨어 플랫폼으로써 MS 윈도우에 도전할 준비가 돼 있는지 리눅스 데스크톱 들을 비교했다.

리뷰는 모두 동일한 방식을 사용했다. 표준 하드웨어 플랫폼에서 소프트웨어를 설치하고 기존 인프라(주로 MS)가 있는 경우 이와의 연동을 위한 기본 기능이 있는지 점검했다. 중요한 기능에는 익스체인지와의 이메일과 캘린더 연결, 네트워크 프린터 연결 지원, 인스턴트 메시징 지원, 패치와 업그레이드를 항상 최신으로 유지하기 위한 소프트웨어 업데이트가 포함된다.

또한 지원의 가용성과 가격도 검토했다. 그리고 데스크톱과 랩톱 모두에서 리눅스 배포판들을 시험했다.

설치

리눅스 배포판 설치는 윈도우 설치와 다르지만 비교적 쉽다는 면에서 유사하다. 또한 윈도우 설치와 마찬가지로 일반 사용자가 아니라 IT 부서원이 하게 된다.

리눅스 설치에 있어서 크게 다른 점은 한두 가지가 있다. 우선 리눅스 배포판은 PC에서 하나의 운영체제가 설치돼 있다고 예상한다. 소프트웨어는 하드 드라이브 파티션을 제안하며 이미 존재하는 윈도우 시스템을 보존한다. 이렇게 되면 듀얼-부트 PC를 갖게 되며 전원을 켤 때 OS를 선택할 수 있다. 물론 리눅스로 전환한다면 듀얼 부트 PC를 공식화할 필요는 없다.

일부 설치 프로그램은 파티션을 쉽게 도와주지 못할 수 있다. 테스트 배포판 중 수세의 YaST2 설정도구가 두드러졌다. 설명이 잘 돼 있고 잘못된 선택에서 빠져나올 수 있게 하며 좋은 반응과 조언을 준다. 불행하게도 테스트 결과 최고의 배포판이라고 여겨진 우분투(Ubuntu)의 경우 설치 프로그램이 가장 안 좋았다.

인스톨 프로그램이 동작하기만 한다면 부가기능으로 리눅스 선택을 할 필요는 없다. 결국 사용시간에 비해 설치시간은 매우 짧기 때문이다.

당신 회사의 필요에 맞도록 데스크톱을 전환하려면 우분투를 먼저 진지하게 검토하는 것이 좋다. 그리고 설치시에 특정 하드웨어를 설정해야 한다.

설치 프로그램은 관리자가 윈도우의 사용자 인터페이스에 해당하는 데스크톱 환경을 선택할 것을 요구한다. 그놈과 KDE가 주요 선택 대상이다. 또한 애플리케이션을 선택하도록 하며 오픈오피스에서 사용될 파일포맷과 같은 것들도 물어본다.

설치 프로그램은 또한 운영체제의 보안을 설정한다. 관리자가 파워유저를 위한 루트 패스워드를 입력하도록 요구하며 최소한 한 명의 사용자(특권이 낮은)를 입력할 것도 요구한다.

YaST2는 또한 패스워드가 충분히 풀기 어렵게 입력될 것을 요구한다. 우분투는 임의의 패스워드를 설정하고 최초의 사용자에게 관리 태스크를 할 수 있도록 함으로써 파워유저라는 개념을 던져버린다. 따라서 윈도우 사용자들이 보다 익숙한 좀 느슨한 환경을 제공한다.

도구

대부분의 경우 제품들은 아래의 것들을 모두 담은 채 출시된다. 하나라도 없다면 다운로드를 통한 설치도 쉬울 것이다. 그러나 도구가 이미 있다면 그리고 잘 통합되어 있다면 시간과 노력이 훨씬 덜 들게 된다. 특히 패키지 내부의 다양한 애플리케이션을 위한 패치와 업그레이드 설치를 위한 업데이트 서비스가 있다면 좋다.

다음은 우리가 주목한 주요 구성요소이다.

그놈 사용자 인터페이스

윈도우와 유사하지만 덜 복잡하다는 면에서 맥과 유사하다. 버밍햄의 테스트 프로젝트의 경우 각 사용자는 각 데스크톱 환경 사용에 이틀씩을 할당 받았는데 사용자들은 KDE 환경보다 그놈을 선택했다고 레스 팀스는 말했다. MS 환경의 열기, 닫기, 최소화에 익숙한 사용자들은 그놈을 바로 사용할 수 있다.

오픈오피스 생산성 스위트

리눅스에서 가장 인기 높은 생산성 스위트이다. 워드나 RTF 파일로 문서를 저장할 수 있다. MS 오피스에 친숙한 사용자들은 즉각적으로 이를 사용할 수 있다. 일부 배포판은 오픈오피스의 메뉴 옵션 설정이 워드 메뉴와 유사하도록 만들어서 놀라운 결과를 가져올 때도 있다. "오픈오피스를 사용하는 일부 사용자는 이것이 MS 애플리케이션이 아닌 줄 모른다"고 팀스는 말했다.

에볼루션 이메일/캘린더/주소록

MS 아웃룩과 너무 닮아서 재교육이 필요 없고 무엇을 사용하는지 잊어버리는 경우가 많다. 이미 사용자들이 주소록을 갖고 있다면 v카드 혹은 CSV(comma-separated variable) 파일의 형태로 아웃룩에서 받아올 수 있다. 대부분의 사용자를 위해 이는 IT 부서에서 해줄 수 있다.

CNET의 기술 팀원들은 상당기간 데스크톱용으로 다양한 리눅스 버전을 사용해 왔으며 익스체인지 이메일과 캘린더를 에볼루션을 통해 사용해왔다. 이들은 종종 잘 되지 않는 것에는 회의 초청장에 대한 답장의 복사본 전송과 같은 난해한 기능이 있다고 말한다. 이런 기능은 사용자들이 원하지 않을 수도 있다.

게임(GAIM) 인스턴트 메시징

게임 클라이언트를 통해 주요 IM 서비스를 모두 접근할 수 있으며 테스트한 모든 리눅스 배포판은 게임을 포함했다. 지디넷 UK의 일부 직원은 윈도우에서 이미 게임을 사용해 다양한 동료와 클라이언트가 사용하는 IM 소프트웨어를 통합하고 있었다. 동시에 야후!와 AOL IM 서비스의 광고도 차단하고 있었다. 따라서 이들에게 리눅스로의 전환은 훨씬 쉬웠다.

프린터 지원

대부분의 배포판은 네트워크 프린터가 추가되는 것을 허용하며 문서의 직접 프린트도 허용한다.(맨드리바에서 네트워크 추가가 가장 어려워 보인다.)

관리와 지원

관리와 지원은 일부에게 중요한 기능이다. 레드햇과 노벨 리눅스 데스크톱과 같은 리눅스 배포판은 연간 지원 계약에 기반해 판매된다. 이는 예측할 수 있는 비용을 제공하며 전화로 지원받을 수 있다는 편리함도 제공한다.

팀스는 "지원은 중요하지만 노벨이나 레드햇과 같은 회사를 통할 필요는 없다. 오픈소스 컨소시엄은 우분투와 같은 배포판을 지원하는 사람들의 긴 목록을 보유하고 있다. 오픈소스와 관련된 다양한 컨설팅 서비스를 제공하는 공동체가 있다. 다양한 중소기업으로부터 훌륭한 서비스를 제공 받은 경험이 있다. 이들 회사는 다른 방법으로 알 수는 없었을 것이다. 좋은 것은 누구도 독점하지 않는다는 것"이라고 말했다.

버밍햄은 연간 라이선스 옵션을 포기했으며 지원계약이 포함된 노벨의 리눅스 데스크톱 대신 SuSE 9.3 데스크톱을 선택했다. 그러나 노벨 브랜드 제품이 그의 시험이 진행도중에 나왔기 때문에 이는 시기상의 문제였다.

똑같이 중요한 것은 회사내부의 관리이다. 리눅스 운영체제의 업데이트 기능은 접근이 가능하고 커스텀화도 가능해야 한다. 따라서 기업내의 데스크톱에 업데이트가 적용될 수 있어야 한다.

젠웍스 데스크톱 관리 제품을 통합하는 노벨의 레드 카펫은 이런 측면에서 두드러진다. 그러나 다른 리눅스 버전도 자동관리 기능을 제공한다.

비 윈도우 애플리케이션

리눅스의 전망이 좋지만 아직 윈도우를 완전히 버릴 준비는 안돼 있다. 한가지 이유가 있다. 내가 의존하고 있는 윈도우 프로그램과 유틸리티이다. 일부는 노력을 하면 리눅스 버전을 받을 수 있으나 질긴 잡초를 잘 보면 뿌리가 엉킨 경우가 많다.

다음은 내가 윈도우를 아직 사용하는 이유다. 일부는 리눅스를 위한 대안이 분명히 존재할 것이다. 그러나 아직 찾지 못했다.

스카이프를 사용한다. 비록 스카이프가 물론 리눅스에서 제공되기는 한다. 맨드리바 리눅스에서 제공되며 다른 리눅스에서도 다운로드와 설치가 쉽다. 그러나 주소록과 메시지에서 자동으로 통화를 가능하게 하는 아웃룩용 스카이프 툴바도 사용한다. 내가 알기로는 에볼루션을 위한 스카이프 툴바는 아직 존재하지 않는다.

블루투스를 이용해 소니에릭슨 휴대폰에서 소니 에릭슨 자체 소프트웨어를 사용해 약속 스케줄을 동기화한다. 아웃룩과 잘 동작하며 PC에서만 사용가능하다.

보이프버스터(Voipbuster)와 같은 다른 IP 전화 서비스는 PC용 클라이언트만 제공되는 경우가 많다.

또한 아웃룩용의 룩아웃을 사용한다. 거대한 .pst 파일에서 메시지와 약속을 신속하게 찾아주는 훌륭한 프로그램이다. 에볼루션은 조직화가 더 잘돼 있고 이와 같은 애드온이 필요 없을 수도 있다. 장기간 사용한 후 이를 알아낼 수 있을 것이다.

구글 데스크톱과 사이드바는 윈도우 전용이다. 그놈은 비글 프로젝트를 통해 곧 비슷한 기능을 제공할 것이다.

원격 스토리지. 공유와 백업을 위해 넷기어 스토리지 센트럴 박스를 갖고 있다. 윈도우 소프트웨어만 지원된다. 또한 스마트싱크로 이 박스와 동기화하는데 이 소프트웨어도 윈도우 전용이다.

더 큰 기업에서는 아마도 더 많은 윈도우 기반 프로그램이 사용되고 있을 것이다. 예를 들어 지방 정부에서는 주택 검사나 등급부여 등의 업무를 위해 다양한 특수 소프트웨어를 사용할 수 있다.

레스 팀스는 소프트웨어 개발자들이 서버와 마찬가지로 클라이언트 애플리케이션도 리눅스 버전을 만들도록 독려한다고 말한다. 그러나 동시에 윈도우 애플리케이션 수행을 위한 다른 방법도 있다.

팀스는 "시험 운용을 했으며 와인에서 애플리케이션 수행에 어려움이 없었다"라고 말했다. 와인 윈도우 에뮬레이터는 포직스 호환 운영체제를 수행하는 x86 기종에서 윈도우 API를 제공한다.

다른 가능성은 시트릭스와 같은 것을 사용해 서버에서 애플리케이션을 수행하고 이를 터미널 윈도우로 연결하는 것이다.

MS 윈도우 관성을 벗자

윈도우 애플리케이션 수행은 이 프로젝트의 범위를 벗어나지만 기업들의 데스크톱이 윈도우에서 벗어나려면 반드시 다뤄야만 하는 주제다. 현재 윈도우 기반 애플리케이션을 꼭 필요로 하지 않는다고 해도 미래에 이는 바뀔 수 있다.

리눅스 데스크톱은 윈도우에 도전할 준비가 돼 있지만 IT 관리자들이 결정을 내려야 한다. 리눅스는 무료일 수 있지만 윈도우는 PC를 구매할 때 이미 들어있다.

리눅스 데스크톱을 작동시키고 윈도우를 끄는 데는 추가의 일이 필요하지만, MS 세계에 우리를 가둬놓고 있는 주요 요인은 점점 더 관성이 아닌가 하는 생각이다.

 내용출처 : ZDNet Korea

신고
Posted by 새우날다 Trackback 0 Comment 0

$sudo apt-get install build-essential

위와 같이 우분투 계열에서는 sudo로 모든걸 해결한다.
그래도 정 루트 권한을 득하고 싶다면

$sudo su

를 사용하던가

$sudo passwd

를 해서 root패스를 설정한 뒤 su로 루트 권한을 가지면 된다.

신고
Posted by 새우날다 Trackback 0 Comment 0

원문 링크 : 리눅스/유닉스 에디터 'vi' (3) - ex 명령어 익히기


ex 명령어 익히기

ex 명령어의 기본형식

:k,l command m - (범위지정) (명령어) (명령이 수행될 위치)

:k,l command
m
:1,10 co 50 1 줄 부터 10 줄 까지를 50 줄 이후로 복사
:34,50 d 34 줄 부터 50 줄 까지 삭제
  :100,150 m 10 100 줄 부터 150 줄까지를 10 줄 이후로 옮김
  :.,$ d 현재줄부터 끝까지 지우기
  :.,+20 co -4 현재줄부터 20줄을, 4줄 위에 복사하기
  :-,+ t 0 위, 아래로 한줄(총 3줄)씩을, 문서 맨위에 복사하기
  :/pattern/ d pattern 이 들어있는 줄 지우기
  :/pattern/ -nd pattern 이 들어있는 줄로부터 n 번째 윗줄 지우기
  :/pattern/ +nd pattern 이 들어있는 줄로부터 n 번째 아랫줄 지우기
  :/p1/, /p2/ d p1 이 들어있는 줄부터, p2 가 들어있는 줄까지 지우기
  :.,/pa/ m 23 현재줄부터 pa 이 들어있는 줄까지, 23번줄 이후로 옮기기
g 옵션 붙이기 :g/pattern 파일전체에서 마지막으로 pattern 이 쓰여진 줄로 가기
  :g/pattern/ p 파일전체에서 pattern 이 있는줄 보여주기
  :g/pattern/ nu 파일전체에서 patterm 이 있는줄을 번호와 함께 보여주기
  :60,124 g/pa/ p 60,124 줄 사이에서 pa 이 들어있는줄 보여주기
저장 및 종료 :w 저장하기
  :q 종료하기
  :wq 저장하고 종료하기
  :x 저장하고 종료하기 (:wq 와 동일)
  :w! 강제로 저장하기 (read-only 로 열었을경우)
  :q! 편집한 내용을 저장하지 않고 종료하기
  :w new_filename new_filename으로 저장하기
  :w %.new 현재파일 이름에 .new 를 붙여서 새로운 파일로 저장
  :230,$ w filename 230 줄부터 끝줄까지 filename으로 저장하기
  :.,580 w filename 현재줄부터 580줄까지 filename으로 저장하기
  :1,10 w new_filename 1줄부터 10줄까지 new_filename으로 저장하기
  :340,$ w >>new_file 340줄부터 끝줄까지 new_file에 추가하기
읽기 :r[ead] filename 현재위치에 filename 읽어들이기
  :r /usr/local /data 현재위치에 /usr/local/data 읽어들이기
  :185 r /usr/ local/data 185줄 이후에 /usr/local/data 읽어들이기
  :$ r /usr/local/data 맨끝줄 이후에 /usr/local/data 읽어들이기
  :0 r /usr/local/data 맨윗줄에 /usr/local/data 읽어들이기
  :/pa/ r /usr/local/data pa 이 존재하는 줄에 /usr/local/data 읽어들이기
다중편집하기 vi file1 file2 file3 :args 편집중인 파일목록 보여주기
  :n[ext] 다음 파일로 넘어가기
  :prev[ious] 이전파일로 돌아가기
  sc/ESC/g BX가 있는줄 찾아서 Esc 를 ESC 로 바꾸
  :% s/editer/editor/g 처음줄부터 마지막줄까지, editer 를 editor 로 바꾸기
  :g/editer/ s//editor/g 위와 동일("s/" 다음에 인자가 없어서 윗줄과 같은효과
신고
Posted by 새우날다 Trackback 0 Comment 0

원문 링크 : 리눅스/유닉스 에디터 'vi' (2) - VI 활용


VI 활용

커서 움직이기

글자 단위 이동 k 위쪽으로
  j 아랫쪽으로
  h 왼쪽으로
  l 오른쪽으로
줄 단위 이동 ^ 줄의 맨앞으로 (빈칸무시)
  0 줄의 맨앞으로
  $ 줄의 맨뒤로
  % 짝을 이루는 기호 확인하기
  + 다음줄의 첫번째 글자로
  - 윗줄의 첫번째 글자로
  n| 현재줄의 n 번째 열로 (n은 임의의 숫자)
  H 화면상에 처음줄로
  M 화면상의 중간줄로
  L 화면상의 마지막줄로
  nH 화면상의 처음줄로부터 n 줄 밑으로
  nL 화면상의 마지막줄로부터 n 줄 위로
  G 맨 마지막줄로 (go)
  nG n 번째줄로
  gg 맨 마지막줄로
  ngg n 번째줄로
  n n 번째줄로
단어 단위 이동 w 한단어 오른쪽으로 (word)
  b 한단어 왼쪽으로 (back)
  e 현재 단어의 끝으로 이동 (end)
  E 현재 단어의 끝으로 이동 (구두점 무시 - 영문자에 해당 - ? . !.)
  ) 다음 문장의 시작으로
  ( 이전 문장의 시작으로
  } 다음 문단의 시작으로
  { 이전 문단의 시작으로
  ]] 다음 섹션의 시작으로
  [[ 이전 섹션의 시작으로
화면단위 이동 Control - F 한화면 밑으로 이동
  Control - B 한화면 위로 이동
  Control - D 반쪽화면 밑으로 이동
  Control - U 반쪽화면 위로 이동
  Control - E 커서는 현재위치 그대로 화면만 한줄씩 위로 이동
  Control - Y 커서는 현재위치 그대로 화면만 한줄씩 아래로 이동
  z 커서의 위치와 함께, 화면상의 맨위로
  nz n번 라인을 화면상의 맨위로
  z. 커서의 위치와 함께, 화면상의 중간으로
  z- 커서의 위치와 함께, 화면상의 맨아래로
  ## Control - G 현재 편집문서의 정보 보여주기
  ## Control - L 화면 재표시 (글자가 깨졌을경우)
  ## Control - R 화면 재표시 (글자가 깨졌을경우) 편집하기 복사, 붙이기, 합치기

편집하기

복사, 붙이기,
합치기
y : 복사하기
yy 한줄복사
  2yy 두줄복사
  nyy n줄 복사 (n 은 임의의숫자)
  yw 한단어 복사
  y2w 두단어 복사
  y$ 그줄 끝까지 복사
  y0(y^) 그줄 처음까지 복사
  yG 문서의 끝까지 복사
  Y 한줄복사 (yy 와 동일)
마지막 명령어의
반복
. 마지막에 수행한 명령어를 반복한다.
2. 명령어를 2번 반복한다.
  p : 붙이기
  p 아래로(오른쪽으로) 붙이기
  2p 아래로(오른쪽으로) 두번 붙이기
  P 위로(왼쪽으로) 붙이기
  2P 위로(왼쪽으로) 두번 붙이기
  J : 두줄 합치기
  J 현재줄을 윗줄에 붙이기 (두줄 합치기)
  3J 세줄합치기
지우기, 복구
하기, 바꾸기
d : 지우기
dd 한줄지우기
  2dd 두줄지우기
  ndd n줄지우기 (n 은 임의의숫자)
  dw 한단어 지우기
  d2w 두단어 지우기
  d$ 그줄 끝까지 지우기
  d0(d^) 그줄 처음까지 지우기
  dG 문서 끝까지 지우기
  D 그줄 끝까지 지우기(d$ 와 동일)
  u : 복구하기
  u 한번복구하기
  2u 두번복구하기
  c : 바꾸기
  cc 한줄바꾸기
  2cc 두줄바꾸기
  ncc 여러줄 바꾸기 (n 은 임의의숫자)
  cw 한단어 바꾸기
  ce 한단어 바꾸기 (공백 제외)
  c2w 두단어 바꾸기
  c$ 그줄 끝까지 바꾸기
  c0(c^) 문서 끝까지 바꾸기
  C 그줄 끝까지 바꾸기 (c$ 와 동일)
  r : 한글자 바꾸기
  r 한글자 바꾸기
  2r 두글자 바꾸기 (r 명령어는 insert 모드로 바뀌지 않는다.)
  R : 바꾸면서 덮어 쓰기
  s : )한글자 지우고 insert 모드로 (cl 와 동일)
  - S : 한줄지우고 insert 모드로 (cc 와 동일)
  ~ : 대문자 <-> 소문자 바꾸기 (영문자에만 해당)
  지우기와 바꾸기의 차이점은 바꾸기 명령어 후에 vi 편집모드로 바뀐다.
찾기 /pattern pattern라는 단어 찾기 (위에서 아래로)
  ?pattern pattern라는 단어찾기 (아래로 위에서)
  / : 찾기반복 - 위에서 아래로
  n : 찾기반복 - 위에서 아래로
  ? : 찾기반복 - 아래에서 위로
  N : 찾기반복 - 아래에서 위로
  fx : 현재줄에서 x문자 찾기 (x 는 한개의 글자)
  Fx : 현재줄에서 반대방향으로 x문자 찾기 (x 는 한개의 글자)
  tx : 현재줄에서 x문자를 찾아서 바로전에 커서놓기
  Tx : 현재줄에서 반대방향으로 x문자를 찾아서 바로후에 커서놓기
  ; : 현재줄에서 한글자 찾기반복
  ' : 현재줄에서 한글자 찾기반복 (반대방향으로)
찾기와 편집
명령의 응용
d/simple simple 이라는 단어가 나올때까지 지우기
d/^scully 줄의 맨앞에 scully 라는 단어가 나올때까지 지우기
  y/yahoo yahoo 라는 단어가 나올때까지 복사하기 편집모드 지정하기
  i : insert 현재커서위치
  10i* * 문자를 10개 집어넣기
  25i=- =- 를 25개 반복하기
  I : 현재커서가 위치한 줄의 맨처음에
  a : append 현재커서위치 바로 다음에
  A : 현재커서가 위치한 줄의 맨끝에
  o : open 현재커서위치 바로 아래줄에
  O : Open 현재커서위치 바로 윗줄에 위치 기억하기
  mx : mark 현재의 커서위치를 x 라는 문자로 기억
  `x : 기억된 x 위치로 이동
  `` : 이동하기 전의 위치로 (제자리)
  'x : 기억된 x 위치의 맨 앞으로 이동
  '' : 이동하기 전 위치의 맨앞으로 이동 버퍼 이용하기
  "xyy : x 라는 이름의 버퍼에 한줄 복사 하기
  "xp : x 라는 이름의 버퍼에 저장된 내용을 붙이기
잠시 쉬었다
가기
:= 현재 줄번호 보여주기
:/pattern/ = pattern 이 위치한 줄번호 보여주기
신고
Posted by 새우날다 Trackback 0 Comment 0

원문 링크 : 리눅스/유닉스 에디터 'vi' (1) - VI 기초 개념 잡기


VI 기초 개념 잡기

커서 움직이기

글자 단위 이동 k 위쪽으로
  j 아랫쪽으로
  h 왼쪽으로
  l 오른쪽으로
줄 단위 이동 ^ 줄의 맨앞으로 (빈칸무시)
  0 줄의 맨앞으로
  $ 줄의 맨뒤로
  % 짝을 이루는 기호 확인하기
  + 다음줄의 첫번째 글자로
  - 윗줄의 첫번째 글자로
  n| 현재줄의 n 번째 열로 (n은 임의의 숫자)
  H 화면상에 처음줄로
  M 화면상의 중간줄로
  L 화면상의 마지막줄로
  nH 화면상의 처음줄로부터 n 줄 밑으로
  nL 화면상의 마지막줄로부터 n 줄 위로
  G 맨 마지막줄로 (go)
  nG n 번째줄로
  gg 맨 마지막줄로
  ngg n 번째줄로
  n n 번째줄로
단어 단위 이동 w 한단어 오른쪽으로 (word)
  b 한단어 왼쪽으로 (back)
  e 현재 단어의 끝으로 이동 (end)
  E 현재 단어의 끝으로 이동 (구두점 무시 - 영문자에 해당 - ? . !.)
  ) 다음 문장의 시작으로
  ( 이전 문장의 시작으로
  } 다음 문단의 시작으로
  { 이전 문단의 시작으로
  ]] 다음 섹션의 시작으로
  [[ 이전 섹션의 시작으로
화면단위 이동 Control - F 한화면 밑으로 이동
  Control - B 한화면 위로 이동
  Control - D 반쪽화면 밑으로 이동
  Control - U 반쪽화면 위로 이동
  Control - E 커서는 현재위치 그대로 화면만 한줄씩 위로 이동
  Control - Y 커서는 현재위치 그대로 화면만 한줄씩 아래로 이동
  z 커서의 위치와 함께, 화면상의 맨위로
  nz n번 라인을 화면상의 맨위로
  z. 커서의 위치와 함께, 화면상의 중간으로
  z- 커서의 위치와 함께, 화면상의 맨아래로
  ## Control - G 현재 편집문서의 정보 보여주기
  ## Control - L 화면 재표시 (글자가 깨졌을경우)
  ## Control - R 화면 재표시 (글자가 깨졌을경우) 편집하기 복사, 붙이기, 합치기

편집하기

복사, 붙이기,
합치기
y : 복사하기
yy 한줄복사
  2yy 두줄복사
  nyy n줄 복사 (n 은 임의의숫자)
  yw 한단어 복사
  y2w 두단어 복사
  y$ 그줄 끝까지 복사
  y0(y^) 그줄 처음까지 복사
  yG 문서의 끝까지 복사
  Y 한줄복사 (yy 와 동일)
마지막 명령어의
반복
. 마지막에 수행한 명령어를 반복한다.
2. 명령어를 2번 반복한다.
  p : 붙이기
  p 아래로(오른쪽으로) 붙이기
  2p 아래로(오른쪽으로) 두번 붙이기
  P 위로(왼쪽으로) 붙이기
  2P 위로(왼쪽으로) 두번 붙이기
  J : 두줄 합치기
  J 현재줄을 윗줄에 붙이기 (두줄 합치기)
  3J 세줄합치기
지우기, 복구
하기, 바꾸기
d : 지우기
dd 한줄지우기
  2dd 두줄지우기
  ndd n줄지우기 (n 은 임의의숫자)
  dw 한단어 지우기
  d2w 두단어 지우기
  d$ 그줄 끝까지 지우기
  d0(d^) 그줄 처음까지 지우기
  dG 문서 끝까지 지우기
  D 그줄 끝까지 지우기(d$ 와 동일)
  u : 복구하기
  u 한번복구하기
  2u 두번복구하기
  c : 바꾸기
  cc 한줄바꾸기
  2cc 두줄바꾸기
  ncc 여러줄 바꾸기 (n 은 임의의숫자)
  cw 한단어 바꾸기
  ce 한단어 바꾸기 (공백 제외)
  c2w 두단어 바꾸기
  c$ 그줄 끝까지 바꾸기
  c0(c^) 문서 끝까지 바꾸기
  C 그줄 끝까지 바꾸기 (c$ 와 동일)
  r : 한글자 바꾸기
  r 한글자 바꾸기
  2r 두글자 바꾸기 (r 명령어는 insert 모드로 바뀌지 않는다.)
  R : 바꾸면서 덮어 쓰기
  s : )한글자 지우고 insert 모드로 (cl 와 동일)
  - S : 한줄지우고 insert 모드로 (cc 와 동일)
  ~ : 대문자 <-> 소문자 바꾸기 (영문자에만 해당)
  지우기와 바꾸기의 차이점은 바꾸기 명령어 후에 vi 편집모드로 바뀐다.
찾기 /pattern pattern라는 단어 찾기 (위에서 아래로)
  ?pattern pattern라는 단어찾기 (아래로 위에서)
  / : 찾기반복 - 위에서 아래로
  n : 찾기반복 - 위에서 아래로
  ? : 찾기반복 - 아래에서 위로
  N : 찾기반복 - 아래에서 위로
  fx : 현재줄에서 x문자 찾기 (x 는 한개의 글자)
  Fx : 현재줄에서 반대방향으로 x문자 찾기 (x 는 한개의 글자)
  tx : 현재줄에서 x문자를 찾아서 바로전에 커서놓기
  Tx : 현재줄에서 반대방향으로 x문자를 찾아서 바로후에 커서놓기
  ; : 현재줄에서 한글자 찾기반복
  ' : 현재줄에서 한글자 찾기반복 (반대방향으로)
찾기와 편집
명령의 응용
d/simple simple 이라는 단어가 나올때까지 지우기
d/^scully 줄의 맨앞에 scully 라는 단어가 나올때까지 지우기
  y/yahoo yahoo 라는 단어가 나올때까지 복사하기 편집모드 지정하기
  i : insert 현재커서위치
  10i* * 문자를 10개 집어넣기
  25i=- =- 를 25개 반복하기
  I : 현재커서가 위치한 줄의 맨처음에
  a : append 현재커서위치 바로 다음에
  A : 현재커서가 위치한 줄의 맨끝에
  o : open 현재커서위치 바로 아래줄에
  O : Open 현재커서위치 바로 윗줄에 위치 기억하기
  mx : mark 현재의 커서위치를 x 라는 문자로 기억
  `x : 기억된 x 위치로 이동
  `` : 이동하기 전의 위치로 (제자리)
  'x : 기억된 x 위치의 맨 앞으로 이동
  '' : 이동하기 전 위치의 맨앞으로 이동 버퍼 이용하기
  "xyy : x 라는 이름의 버퍼에 한줄 복사 하기
  "xp : x 라는 이름의 버퍼에 저장된 내용을 붙이기
잠시 쉬었다
가기
:= 현재 줄번호 보여주기
:/pattern/ = pattern 이 위치한 줄번호 보여주기
신고
Posted by 새우날다 Trackback 0 Comment 0

원문 링크 : 리눅스/유닉스 에디터 'pico'


리눅스/유닉스 에디터 'pico'

홈페이지를 만들기 위해 HTML 에디터 프로그램으로 나모와 프런트 페이지등을 많이 사용하듯이 유닉스 시스템에서는 pico 나 vi 와 같은 편집기 프로그램을 많이 사용합니다.
편집기는 telnet 으로 서버에 로긴후 pico 또는 vi 라고 입력하기만 하면 되고 그중 PICO 편집기는 별도의 도움말이 필요 없을 정도로 하단의 Help 메뉴를 보면서 쉽게 사용하실 수 있습니다.
아래는 편집기 프로그램중 가장 많이 사용되고 가장 기본적인 VI 에디터에 대한 명령어에 대한 안내와 pico에 대한 설명입니다.
가급적 유닉스 기반 시스템에 익숙하지 않은 초보자라면 pico 편집기를 사용하실 것을 권하며 보다 다양한 기능을 복잡한 편집기를 원하실 경우에는 vi 를 사용하시면 됩니다.

PICO 사용법

pico 를 불러낼 땐 telnet 으로 로긴한 상태에서 pico 라고만 타이핑하시면 됩니다.
또는 직접 파일을 편집하려면 pico filename 이라고 하시면 됩니다. 그럼, pico 의 화면이 나타납니다.
왼쪽위에 pico 의 버젼이 나타나고 중간에는 편집하고 있는 파일이름이 그리고 오른쪽위 에는 처음에는 아무 것도 안 나타나다 가 글을 쓰기 시작하면 'Modified'라고 나타납니다.
Modified 란 현재의 설정 상태에서 "변경되었다" 라는 뜻입니다. 처음 파일을 불러올 때와는 어떻게든 변경이 되었다라는 표시 입니다. 그리고 화면의 하단에 보시면 몇가지 단축키에 대한 설명이 나옵니다.
pico 의 단축키를 하나씩 따라 해보도록 합시다.

먼저 ^G(Ctrl + G) 글쇠는 "도움말보기" 입니다.
Pico Help Text 라고 해서 pico 에 대한 간단한 설명이 나옵니다.

피코는 pine 메일 프로그램과 이용방법이 아주 비슷하며 간단하고 쓰기 편한 문서에디터를 위해 디자인되었습니다.
제일 상단의 라인은 피코 프로그램의 버젼을 나타냅니다.
현재의 파일을 편집하셨다면 그 변경된 내용은 아직 저장되지 않았으며 타이핑된 내용들은 현재 커서위치에서 자동적으로 버퍼로 삽입이 됩니다.
편집명령과 옆에 있는 화살 표 글쇠에 의한 커서이동은 특수한 ctrl 글쇠 조합에 의해 피코에게 전달됩니다.
'^' 표시는 'Ctrl(콘트롤)'글쇠를 나타내고 'CTRL'글쇠로 나타내기도 합니다.
따라서 Ctrl+q 글쇠는 '^Q' 로 나타납니다. 아래의 단축키는 피코에서 사용가능 한 것입니 다.

도움말 보기

현재의 상태에서 '^G'를 누르면 도움말 화면이 나타납니다.
'^V'를 누르면 다음페이지로 넘어가고(PageDown) '^Y'를 누르면 앞화면으로(PageUp) 갑니다.
도움말 에서 빠져나오시려면 '^X' (Ctrl 키를 누른 상태에서 X를 누르시면 됩니다.)

커서이동

상/하/좌/우 화살표 글쇠와 페이지 업다운 글쇠로도 이동이 됩니다.
그러나 다음과 같이 사용하셔도 됩니다.

^F 현재 커서있는데서 한글자 앞으로 가기
^B 한글자 뒤로 가기
^P 한줄위로 가기
^N 현재 줄의 처음으로 가기
^A 현재 줄의 마지막으로 가기
^V 한 쪽 앞으로 가기
^Y 한 쪽 뒤로 가기

편집기능

^W 파일내에서 특정 글자를 검색하는 키입니다. 이 글쇠를 누르시면 'search :' 라고 나옵니다.
이 부분에 찾기 원하시는 글자를 타이핑한후 엔터를 치면 해당 글자가 있을 경우는 커서가 해당 검색에로 이동이 되고 없을 경우에는 Not Found 라고 나옵니다.
^L 화면다시 보여주기(리플레쉬
^D 현재 커서 위치의 글자 지우기. 리눅스에서는 del 글쇠가 작동하지 않습니다.
이때는 백스페이스를 이용할 수도 있지만 본 명령어를 이용하실 수 있습니다. ^^
현재 커서가 있는 위치부터 블럭설정시작. 이걸 착각하기 쉬운데 'Ctrl + 6' 글쇠를 누르면 블럭설정이 됩니다. 화살표로 조정하시고요. '6'글쇠위에보면 '^'표시가 되어있습니다.
^K 블럭으로 선택된 문장 자르기. 붙이기를 하기 위해서 먼저 원하는 만큼 잘라야 합니다. 블럭을 설정않고 이 글쇠를 누르면 현재 커서 가 있는 한 줄만 자릅니다. ^U 붙이기. 커서를 원하는 데로 옮겨 놓고 이 글쇠를 누르면 그곳에 붙여 집니다. ^I 현재 위치에서 Tab 문자 넣기
^T 영어 스펠링 체크하기
^C 현재 커서위치에 대한 정보
^J 문단을 정렬하는 기능입니다.

파일관련작업

^R 현재 커서위치에 외부파일 끼워넣기. 이 글쇠를 누르면 선택할 수 있는 글쇠가 나타납니다.
'^G'는 이 명령에 대한 간단한 설명보기 이고 '^T'는 파일 이름을 잘 모를 때 파일들이 있는 곳에 가서 찾을 수 있습니다.
그 파일 위에서 엔터를 찍으면 그 위치에 그 파일의 내용이 삽입됩니다. '^C'는 당연히 명령취소입니다.
^O 현재 버퍼를 파일로 저장.
^X 피코 끝내기
신고
Posted by 새우날다 Trackback 0 Comment 0

[펌] 부요 리눅스

2007.08.02 21:32 : 컴퓨터
국내 리눅서들의 기대를 한 몸에 받고 있는 부요가 드디어 그 실체를 드러냈다. 1여년의 개발기간 끝에 나온 부요는 그동안 리눅스 발전의 저해 요인이었던 호환성, 신뢰성을 가장 중요한 테마로 잡았다. 이를 바탕으로 국내 엔트리급 시장부터 엔터프라이즈 시장까지 범용적으로 확대할 계획이라고 밝혔다. 앞으로 국내 리눅스의 표준으로 자리 잡게 될 부요에 대한 모든 것을 준비했다.

정부는 2004년 이후 공개 소프트웨어 활성화 지원 정책을 강력히 추진하고 있다. 우리나라 뿐 아니라 여러 유럽 국가들도 30여개 이상의 공개 소프트웨어 기술 개발 프로젝트와 활용 촉진을 위한 프로젝트를 수행하고 있으며, 중국은 국가안보 확립과 기술 자립국 실현이라는 정책적 목표 아래 공개 소프트웨어 개발과 도입 확산에 적극적으로 정책을 마련하고 있다. 일본 역시 공개 소프트웨어를 소프트웨어 분야의 핵심기술로 인식하고 중앙정부와 지방자체단체, 특히 홋가이도, 나하시, 기후현, 스모토시가 가장 활발한 정책을 펼치고 있다. 이처럼 정부 차원의 공개 소프트웨어 활성화 지원 정책이 계속되고 있음에도 불구하고 국내 리눅스 시장은 여전히 정체되고 있다. 그 이유는 무엇일까.

리눅스로 대표되는 공개 소프트웨어 산업이 우리나라에서 활성화되지 않는 이유는 다음 세 가지이다. 첫째, 이미 개발되어 공개된 8만 여개의 공개 소프트웨어와 개발 중인 10여만 개의 공개 소프트웨어 가운데 어떤 것을 골라 써야 하는지, 그 고른 것이 과연 제대로 쓸 수 있는지를 알 수 없기 때문이다. 또 다양한 공개 소프트웨어의 조합으로 이루어진 최종 솔루션 사이에 호환성이 문제가 된다. 둘째, 공개 소프트웨어 사용자에 대한 효과적인 기술지원이 없기 때문이다. 국내 리눅스 업체의 규모가 작아서 전국적인 지원이 불가능하고 무엇보다도 주인 없는 공개 소프트웨어에 대한 사용자들의 불안감이 여전히 존재하여 사용하기를 주저하고 있다. 마지막으로 공개 소프트웨어를 사용하더라도 외국 리눅스 업체의 제품을 사용하는 것이다.

이상의 문제점인 호환성 결여, 신뢰성·안정성 미흡을 해결하기 위해 국내 관련 기업과 소프트웨어진흥원 그리고 한국전자통신연구원(ETRI)가 협력체를 이뤘다. 먼저 국내 표준 규격을 제정하고 그 규격에 맞고 외국 제품에 비해 성능과 기능이 떨어지지 않는 표준 공개 소프트웨어 컴퓨팅 플랫폼(Booyo, 부요로 명명함)을 개발하는 것이 목표이다. 그리고 부요를 기반으로 만든 국내 제품을 공인인증기관이 철저한 검사를 통해 인증하여 국산 제품 간의 호환성을 유지하며, 공공기관 사용자를 위해 전국적인 기술지원 네트워크를 구성하여 부요에서 발생하는 고객지원 업무체제를 구축하는 것이다.

부요 규격 개발을 위한 추진체계로는 관련 기업 협력체, 공개 소프트웨어 기반의 솔루션 발굴을 위한 국내 대학, 부요 표준화를 위한 TTA 및 OSDL(Open Source Development Lab.), 한중일 OSS (CJK Open Source SW) 활성화 포럼 단체 등으로 구성된다.

이러한 부요 규격인 자국의 표준 운영체제 플랫폼 기술을 확보함으로써 국내 ISV 솔루션 개발의 용이성과 특정 SW 사용에 의한 독과점 방지를 통한 공정경쟁 환경 조성 및 소비자 선택권 확대 등의 효과를 기대하며, 최근 논의되고 있는 한중일 3국의 기술협력으로 제3의 글로벌 제품 개발에 있어 우리나라도 주도적인 역할을 수행할 수 있다는 점이다.

날아오르는 펭귄을 상징
공개 소프트웨어 활성화 장애 요인을 제거하기 위해 국제산업 표준을 근간으로 하는 국내 표준 컴퓨팅 규격인 부요의 등장은 이처럼 남다른 의미를 가졌다. 부요라는 단어 역시 그러한 의미를 살리기 위해 결정된 이름이다. 우리나라 민요 가운데 까투리 사냥에서 중간에 까투리를 풀 섶에서 나와 날아오르도록 놀라게 하는 소리가 있다. 남쪽 지방에서는 ‘훠이여’ 북쪽 지방에서는 ‘우여’ 중부 지방에서는 ‘부요’라고 외친다. 즉 부요라는 이름은 리눅스의 희망과 도전 정신을 나타내는 펭귄을 날아오르게 하자는 의성어이다. 부요를 통해 펭귄을 날아오르게 해 리눅스 산업도 크게 일어날 것이라는 희망을 담고 있다. 그래서 부요의 로고도 펭귄이 날아오르는 모습이다. 또한 부요란 말은 한자로 풍요롭다는 의미인 ‘富饒’와 발음이 같아  소프트웨어 산업을 부유하고 넉넉하게 하겠다는 의도도 담겨져 있다.

부요 규격 발전 방향
부요는 데스크탑 규격과 서버 규격으로 구분된다. <그림 1>은 부요의 규격 로드맵이며 이는 <그림 2>의 리눅스 Hype Cycle를 기반으로 계획된 것이다. 리눅스 기술이 지난 몇 년 동안은 1~4 프로세서 환경인 엔트리급 서버 환경에서 발전해 왔지만, 향후에는 성능·기능 개선, 보안 기능 강화로 64비트 프로세서, 8프로세서 이상의 엔터프라이즈급 서버로 중요업무 솔루션을 수행하는 환경에서 발전하게 될 것이다.

기능·성능 향상을 위해서는 OSDL의 CGL(Carrier Grade Linux), DCL(Data Center Linux) 표준 규격을 따라야 한다. 데스크탑의 경우는 제한적인 업무 사용자를 우선적으로 목표하고 점차적으로 윈도우 환경과 같이 일반 사용자를 지원하는 방향으로 설정한다.

부요 개발에 관련되는 국제표준, 워킹그룹과 프로젝트들
부요 규격 개발에 관련되는 국제 표준은 다음과 같다.

◆ LSB(Linux Standard Base) : 프리 스탠다드 그룹 주도하의 리눅스 운영체제와 유틸리티 기능에 대한 표준. 현재 2.0 버전 진행
◆ FHS(Filesystem Hierarchy Standard): 디렉토리 구조나 파일의 위치에 대한 표준으로 애플리케이션 호환성을 보장하기 위함. 현재 2.3 버전 진행
◆ Open I18N(Open Internationalization) : 제품이나 서비스를 특정 지역의 언어나 문화에 맞추는, 즉 현지화 과정을 쉽게 할 수 있도록 규격을 제정
◆ CGL 규격 : OSDL 주도하의 다수의 컴퓨터 및 통신업체가 리눅스를 엔트리/엔터프라이즈급 시스템 등에 활용할 수 있도록 사실상 표준(de-facts standard)으로 리눅스 기능 규격. 버전 3.0까지 제정
◆ DCL 규격 : 리눅스를 중대형 시스템에 적용할 수 있도록 정의한 리눅스 규격으로 2004년 초부터 DCL 1.0 제정을 위해 회원사 모집 및 진행
◆ DTL(DeskTop Linux) 규격 : 데스크탑 기능 규격을 제정하기 위해 2004년 하반기부터 활동 시작
◆ DMTF(Distributed Management Task Force) CIM(Common Information Model)/WBEM 표준 : 시스템 관리의 정보 표준모델 및 기능, 구조에 표준 제정, 2001년부터 활동 본격화
◆ DMTF-UC(Utility Computing) 표준 : DMTF CIM/WBEM 표준 기반으로 유틸리티 컴퓨팅 환경을 구현하기 위한 표준 제정
◆ SA(Service Availability) AIS(Application Interface Spec.) : 차세대 HA 클러스터 기능 규격 제정
◆ SA(Service Availability) HPI(Hardware Platform Interface) : 서버 하드웨어 진단, 관리 규격 제정

또한 부요 규격 개발에 있어 페도라(Fedora) 프로젝트, source forge.net 사이트의 공개 프로젝트들, OSDL의 SIG(Special Interest Group) 프로젝트, KLDP 용어 한글화 프로젝트를 참조하고 있으며, OSDL CGL, DCL, DTL 워킹그룹과 CJK OSS 기술개발 워킹그룹과 표준화 워킹그룹 활동을 병행하고 있다.

부요 데스크탑 개발은 이렇게
부요 데스크탑은 <그림 3>과 같이 오피스, 인터넷 뱅킹과 같은 기업업무용 응용, 멀티미디어 장치 지원, 게임, 개발환경과 같이 일반 사용자를 위한 윈도우 환경을 제공하며, 순수 커널 버전 2.6.10과 시스템 서비스를 구성하는 패키지들로 구성된다. 특히 부요 데스크탑 1.0에서는 기업업무 환경에 초점을 두었는데, 특히 다음과 같은 주된 사항을 고려했다.

◆ LSB(Linux Standard Base) 등 산업 표준 규격을 기반으로 하는 개방형 구조 제공
◆ 기존 대중적인 데스크탑 운영체제 대비 리눅스의 부족 기능 해결
◆ 국내 사용자 환경을 위해 표준 한글 사용 환경과 한글처리 기능을 제공
◆ 설치가 용이하고, 원격 업데이트 지원체제 제공
◆ 데스크탑 환경 개선과 주변 장치 지원
◆ GNOME 기반의 사용자 친화적인 데스크탑 환경 제공
◆ 서버 중심의 리눅스를 데스크탑용으로 가볍고 빠른 데스크탑 환경 제공
◆ 오피스, 인터넷 뱅킹과 같은 기업업무용 환경 제공

 

사용자에게 친화적인 환경 제공
기존의 대중적인 데스크탑 OS 사용자에게 부요 데스크탑 사용시 사용자 친화적인 환경을 제공하기 위해 아이콘, 색감, 메뉴 구성 트리 등 사용 습관 호환성을 제공하고자 한다. 부요 데스크탑 환경은 GNOME 2.10을 기반으로 한다. 복잡하고 정리되지 않은 메뉴 구조를 개선하기 위해 데스크탑 리눅스 표준이라고 할 수 있는 freedesk top. org의 표준 중에 menu-0.9 스펙을 기반으로 구현했다. 메뉴는 하위 3단계로 구성했으며, 중복되는 메뉴를 줄이고 적절하지 않은 위치의 메뉴를 이동시켜 사용자가 원하는 프로그램을 쉽게 찾을 수 있도록 했다. 프로그램 아이콘 이름도 도구 이름과 설명 문구, 예를 들어 GIMP를 GIMP 이미지 편집기로 명명하여 어떤 종류의 응용 프로그램인지를 쉽게 알 수 있도록 했다.

테마와 바탕화면 디자인에서도 사용자에게 친근함을 제공할 수 있는 다양한 부요 전용 테마 패키지 등 전체적으로 통일성을 주었고, 아이콘 역시 친근하고 GNOME과 KDE에서 공동으로 사용할 수 있는 포맷의 아이콘 테마 집합을 제공한다. 또한 Truetype 폰트 환경에서 한글의 경우 작은 크기 문자의 경우 흐리게 출력되는 문제를 해결하기 위해 비트맵 폰트를 내장했다. <화면 1>은 부요 데스크탑 환경을 나타낸다.

부요 데스크탑 기본 문자셋트는 ko_KR이며, 인코딩 환경은 UTF-8이다. UTF-8로의 전환은 세계적인 추세이며 다국어 환경에 최상의 인코딩 환경이기 때문이다. 이 때문에 부요 데스크탑은 대중적인 OS 환경의 CP949 및 이와 호환되는 유닉스, 리눅스 환경에서 EUC-KR 인코딩과 호환되지 않는 문제가 있다.

이러한 문제점을 해결하기 위해 인코딩 변환 작업이 파일 전송 및 파일 편집시 필요하다. FTP로 데이터 이동, 파일 롤러 압축 프로그램을 이용한 경우, Samba(SMB)를 통해 대중적인 데스크탑 OS 네트워크 환경을 통한 데이터 이동 및 웹 브라우저를 통한 데이터 이동 시 파일 호환성 문제를 해결했다. 또한 GNOME 데스크탑 환경에서는 별도의 배터리 관리 프로그램을 통해 전원을 관리한다. 화면보호기 경우는 화면보호기 메뉴를 선택하게 되면 현재 로그인한 사용자의 정보를 파악 후 로그인한 사용자가 루트(root)일 경우 에러 메시지를 보여주고, 루트가 아닌 경우에는 기존의 화면보호기를 실행시켜 줌으로써, 루트 사용자의 보안 경각심을 강화시켰다.

리눅스 데스크탑에서 사용자 인터페이스 측면 중 중요한 부분이 한글 환경이다. 부요 데스크탑에서는 한글 표준화를 제안하고 데스크탑 환경 내 응용 프로그램 이름, 메뉴, 메시지 등에 사용하는 용어들을 통일했다. 또한 키보드 한/영 키를 이용하여 한글과 영어를 전환할 수 있도록 지원하며, 외부 장치를 마운트할 경우 한글 문제를 해결했다. 웹 브라우저에 대한 국내 사용자의 편의를 위해 파이어폭스 한글화도 진행됐다.

더욱 가볍고 빠르게
리눅스는 서버 중심으로 개발됐으며 많은 데몬들을 기본적으로 제공해줘야만 한다. 하지만 데스크탑은 서버와는 달리 낮은 사양, 저장 장치, 메모리 등 기타 하드웨어 측면에서 효율적으로 운영되어야 하며, 멀티미디어, 오피스 등 원격지 중심이 아닌 개인 사용자의 중심에서 서비스들을 제공해야 한다. 또한 서버는 항상 컴퓨터의 전원이 공급되는 반면, 데스크탑은 사용할 때만 시스템을 가동하기 때문에 개인이 사용하고자 하는 순간에 쉽고 빠르게 부팅되길 희망한다. 따라서 리눅스 데스크탑의 최적화 기술로 개인 사용자가 좀 더 쉽고 빠르게 사용할 수 있게 하여 적극적인 리눅스 데스크탑의 이용을 이끌어 내도록 했다. 부요 데스크탑의 최적화 기술은 부트 스플래시(splash) 패치를 적용하여 데스크탑 화면 시작과 종료 시 부팅·종료 화면으로 복잡한 정보 출력을 피하고 그래픽 환경의 부팅을 지원하여 좀 더 사용자 친화적인 화면을 제공했다.

복잡한 정보 출력 제거뿐만 아니라 기존 부팅시 순차적으로 서비스 데몬이 실행됐지만, 병렬 부팅을 지원하도록 해 서비스 데몬을 동시에 실행시켜 부팅 시간을 최소화했다. 그 결과 부요 데스크탑 1.0 개발에 참조됐던 페도라 코어 3 기준 시스템 관련 패키지, 네트워크 관련 패키지 등의 기본적으로 제공되는 서비스 수를 55% 이상 줄였으며, 활성 패키지 수도 50% 정도 줄였다. 즉, 기존의 리눅스 데스크탑 솔루션은 최대한 많은 서비스를 제공하는 반면, 부요 데스크탑에서는 필요한 서비스만을 제공하므로써 효율성을 극대화하고 서비스를 최적화했다.


 

< 표 1>과 <그림 4>는 부요 데스크탑과 타 솔루션간의 패키지 수, 용량, 데몬 수 비교와 설치 및 부팅 시간 비교를 나타낸다. 부요 데스크탑은 부팅 시간을 1분 이내로 지원한다. 부트 최적화뿐만 아니라 커널 컴파일 옵션과 형상 설정을 통해 커널의 서비스 정책 변경과 서버용 기능들을 적용하지 않도록 했다.

부요로 인터넷 뱅킹도 가능
부요 데스크탑에서는 인터넷 뱅킹 업무를 수행할 수 있도록 브라우저 플러그인 모듈을 지원한다. 국내 인터넷 뱅킹 서비스를 위한 웹 컨텐츠는 마이크로소프트(이하 MS)의 인터넷 익스플로러(이하 IE) 위주로 작성되어 리눅스에서는 한글과 페이지 깨짐이 발생한다.

즉 IE에서는 액티브X 기술 기반의 다양한 모듈이 탑재되어 실행 가능하다. 이 액티브X를 사용하여 로그인, 카드 결제, 인터넷 뱅킹 등 많은 기능을 하는 플러그인을 설치하여 사용하고 있다. 이에 대해 부요 데스크탑의 모질라는 XPCOM(Cross-Platform Component Object Model)으로 확장된 기능을 구현해 웹 브라우저에 다양한 플러그인 모듈을 사용할 수 있다.

자연스러운 Cut/Paste 환경 지원
윈도우 환경에서는 Cut/Paste가 일관성있게 동작하고 데이터 교환이 제대로 이루어지지만, X윈도우 환경 하에서는 표준이 없어서 Cut/Paste가 제대로 이루어지지 않는다. 부요 데스크탑에서는 X윈도우 환경 하에서 응용 프로그램끼리 Cut/Paste가 자연스럽게 이루어지면서 데이터 교환을 원활히 할 수 있도록 했다. 이 사업에서 개발되고 있는 클립보드 프로그램 이름은 Bclipboard라 이름붙였다. Bclipboard 구조는 <그림 5>와 같으며, 클립보드 동작에 필요한 주요 요소들은 다음과 같다.

◆ 클립보드 서버 : MS에서는 데이터의 보관을 OS 레벨에서 하지만, X윈도우에서는 응용 프로그램끼리 데이터를 주고받아야 한다. Cut한 응용 프로그램이 종료하면 그 데이터도 따라서 사라지게 된다. 이를 방지하기 위해 응용 프로그램의 종료 뒤에도 데이터를 보관해 주는 서버가 필요하다.
◆ 이력 관리기 : 클립보드 데이터의 히스토리를 보관하고 이를 관리한다.
◆ 클립보드 제어 : X윈도우 환경에서의 클립보드에는 owner와 requestor가 존재하기 때문에 owner와 requestor간 데이터를 제어한다.
◆ 데이터 교환 포맷 : 부요 데스크탑에서는 응용 간 데이터 변환을 위해 XML를 사용한다.

 

기존의 공개 소프트웨어인 Gcm, Klipper, Gclipboard와 BClip board를 <표 2>와 같이 비교해 보았다.


 

USB, 무선 인터넷 자유자재로 사용 가능
부요 데스크탑에서 하드웨어 장치 편이를 개선하기 위해 우선적으로 USB 장치와 노트북 사용자를 위한 무선랜 장치를 고려했다. USB 장치 경우, 대중적인 데스크탑 OS 계열과 유사하게 장치에 대한 관리와 USB 응용 매니저를 자동적으로 수행되도록 했으며, USB 드라이버 업데이트 지원과 USB 장치에 대한 한글 파일명, 고용량 메모리 지원, 쓰기 금지 장치 및 암호가 걸린 메모리 장치를 지원토록 했다. 무선 인터넷 경우도 액세스 포인트 검색, 사용자가 편리하고 쉽게 무선 인터넷을 사용할 수 있도록 자주 사용되는 정보들을 저장하는 기능을 지원하는 무선 인터넷 매니저를 제공한다.

다양한 기능을 통합할 수 있는 개발도구 환경
소프트웨어 통합개발환경(IDE, Integrated Development Environ ment)은 소프트웨어 편집기, 컴파일러, 코드 분석 도구, 테스팅 도구, 디버거 등 서로 다른 기능을 가지는 다양한 도구를 포함해야 한다. 따라서 부요 통합개발환경에서는 각종 개발도구를 기능적으로 포괄하는 IDE 기본 환경에 각종 개발도구를 포함할 수 있는 플러그인 기술, 디버깅을 위한 이벤트 모니터링 기술, 각종 템플릿 지원과 광범위한 개발언어 지원, 한글화 등 사용자 편의성을 향상시키고자 한다.

개발도구는 오픈소스 기반 통합개발도구의 대명사인 이클립스 IDE를 기반으로 코드 기반 검증도구를 플러그인하는 형식을 취한다. 이클립스 IDE는 기본 데스크탑 응용 계층에서 제공하는 JRE 또는 JDK를 이용하여 사용자에게 통합개발도구의 기능을 제공한다. 이클립스 IDE는 자바 기술과 플러그인 기술을 이용하여 기본적으로 이클립스에서 제공하는 자바 프로그램 개발 외에 사용자가 원하는 기능들을 추가할 수 있다. 이와 같은 플러그인 기술을 이용하여 프로그램 개발 과정 중에 발생하는 사용자의 다양한 요구 사항들을 충족할 수 있다. 예를 들면 자바 프로그램 개발 외에 웹, C/C++, UML, GUI 프로그램 개발과 같은 사용자의 요구 사항들을 모두 수용할 수 있다.

이클립스 IDE를 기반으로 한 통합개발도구는 신뢰성과 객관성을 보장하는 프로그램 개발을 위해 소스코드 기반 검증도구를 플러그인한다. 소스코드 기반 검증도구와 이클립스 IDE간의 데이터 통합을 위해 공통으로 사용되는 데이터의 스키마를 정의하고 공유함으로써 이루어진다. 따라서 부요 개발도구에서는 <그림 6>과 같이 XML 저장소를 설계하고 XML 저장소를 기반으로 소스코드 기반 검증 도구 외에 프로그램에 대한 복잡도 분석 도구를 통합한다.

부요 서버 개발은 이렇게
이제부터는 부요 서버에 대해 알아보자. 앞에서 기술한 부요 데스크탑의 사용 환경 개선, 리눅스 데스크탑의 부족한 기능 개선 등 대부분의 특징은 부요 서버에서도 적용되어, 부요에서 데스크탑이나 서버 사용 환경은 동일하다. 그러나 커널에서는 차이점이 있다. 데스크탑의 경우는 빠르고 가벼운 커널로 구성하는 반면, 서버에서는 국제 산업 표준을 만족하고 고성능, 고가용성, 고신뢰성을 보장하면서 엔트리급, 엔터프라이즈급 서버 환경을 안정적으로 지원해야 한다. 따라서 부요 서버는 다음과 같은 개발 목표를 가졌다.

◆ LSB2.0.3, FHS2.3 등 국제 산업 표준 만족
◆ 리눅스 기능 강화를 위한 CGL, DCL 규격 만족
◆ 풍부한 서버 개발 도구 제공
◆ 고부하 지속 환경 및 서버 성능 벤치마킹에서 국외 제품과 동일 기능, 성능 제공
◆ 공개 소프트웨어 기반의 보안, 시스템관리, 서버 가상화, 웹, DBMS 등 솔루션 제공

 

현재 리눅스 커널이 2.6까지 발전해왔지만, 국외 기술 분석지에 따르면 2008~2009년 정도에 유닉스 대비 기능적, 성능적으로 대등한 운영체제가 될 것이라 분석하고 있다. 즉 엔터프라이즈 시장에 리눅스 기술이 적용되기 위해서는 여전히 기능 개선, 구현이 필요하다는 의미이다. 2000년에 설립되어 현재 다수의 대형 소프트웨어 업체가 참여하고 있는 비영리단체 OSDL의 CGL, DCL 규격 명세서는 리눅스 운영체제가 미래에 케리어급 또는 엔터프라이즈급 운영체제로 발전하기 위해 필요한 기능을 요구 사항 형식으로 기술하고 있다. 특히 CGL 경우에는 예전의 독점적인 통신 시스템에서 개방형 구조의 시스템으로 하드웨어가 전환되고 있는 시점에 소프트웨어도 개방형 구조인 리눅스 기술을 적용하기 위해 추가적으로 요구되는 기술을 정의하는 규격 문서이다. 그러나 CGL 규격 명세서는 통신 시스템에 국한된 것이 아니라 서버 시스템이 엔터프라이즈급으로 변모하기 위해서도 필수적인 기능을 정의하고 있다. 따라서 부요 서버에서는 CGL 규격 반영 시 모든 규격을 개발하는 것보다 서버 시스템에 필수적이며 다른 기능과 상호 도움이 되는 것을 선택적으로 개발한다.

이 CGL은 2002년 8월에 CGL 규격 1.0 발표 이후, 현재 CGL 규격 3.1 작업을 진행하고 있다. DCL은 엔터프라이즈급 운영체제로 발전하기 위한 규격을 정의하며, 현재 규격 DCL 1.0까지 작업되어 있다. DCL에서는 CGL에서 정의된 규격 이외에 시스템 확장성과 성능을 우선적으로 하고 있다. 결론적으로 부요 서버는 리눅스 커널 2.6을 기반으로 기능과 성능 향상을 추구하기 위해 CGL, DCL 규격으로 개발되고 있다. <그림 7>은 부요 서버 소프트웨어 구조이다. 리눅스 커널뿐만 아니라 공개 소프트웨어의 웹, 데이터베이스 솔루션 등과 최근에 이슈가 되고 있는 표준 기반 시스템 관리 기술과 서버 가상화 기술도 제공한다. 이들 기술은 이 글의 뒷 부분에서 다시 다룰 예정이다.

부요 서버는 커널 2.6.10을 기반으로 페도라 프로젝트의 서버 서비스 데몬 등의 패키지들로 구성된다. 커널은 네 가지의 작업 방향을 통해 개발된다. 첫 번째 방향은 kernel.org의 공개 커널을 통한 기능의 개선이고, 두 번째는 주요 커널 개발자들의 공식 커널 패치를 이용한 기능 개선이다. 세 번째는 앞의 두 가지 방향으로 개발된 커널에 대한 기능, 성능 및 고부하 시험을 통해 도출된 개선점에 대한 수정이다. 마지막 개발 방향으로 CGL, DCL 규격 명세서를 기반으로 한 자체 분석을 통해 얻어진 부족한 부분에 대한 개발 작업이며, 이 작업을 통해 타제품에서 제공하지 않은 기능을 먼저 제공할 수 있다.

이제부터 부요 서버 커널의 기능을 자세히 알아보자. 일반적인 프로세스 관리, 메모리 관리 및 입출력 관리 측면보다 CGL 2.0 규격 명세서를 기반으로 커널 2.6에 추가·강조된 기능에 대해 표준, 성능과 확장성, 가용성, 편리성, 보안, 관리성 측면으로 구분한다.

국제 표준 기능은 반드시 만족
시스템 개발자나 사용자 모두에게 혼란을 방지하려면 API, 파일 시스템 디렉토리 구조, 소프트웨어 설치 방법과 배포 방법 등을 정의해야 한다. 이를 위해 리눅스 개발 업체들의 주도하에 LSB가 제안됐고, 모든 리눅스 배포판들은 이 표준 인터페이스를 따르고 있다. POSIX에서 정의한 다음과 같은 필수적인 기능도 만족한다.

◆ 다중 쓰레드 수행 중 특별한 지점에서 쓰레드들 사이의 동기화를 위한 Barrier 기능
◆ 다중 쓰레드가 공유 데이터에 대한 접근을 허용하는데 사용되는 스핀락 기능
◆ 프로세스/쓰레드의 스케쥴링 변수 설정 및 정책 방식 설정 기능
◆ 특별한 프로세스/쓰레드 수행 시간을 측정하기 위한 타이머 기능
◆ 특정 클럭에 의해 측정된 시간이 지정된 시점에 도달하거나 지정한 값을 지났을 때 쓰레드에게 알릴 수 있는 기능
◆ 어떤 클럭을 선택할 것인가를 결정하는 기능
◆ 프로세스들이 동일한 주소 공간을 공유하지 않고 통신을 하거나 동작을 동기화할 수 있도록 허용하는 기능
◆ 기존 시그널 함수와 호환성을 유지하면서 응용 프로그램에게 비동기적 시그널 통지가 가능하도록 해주는 향상된 시그널 기능
◆ 공유 자원에 대한 배타적 사용을 지원하는 기능
◆ 프로세스나 쓰레드가 대기 상태로 있는 시간을 설정하는 기능
◆ IPv6 기능
◆ 메모리 자원 로깅 기능

 

또한 부요 서버의 쓰레드는 쓰레드 생성 및 소멸에서 성능 측면에서 우수한 NPTL(Native POSIX Thread Library)을 제공한다. 멀티미디어 응용 서비스 등의 전송을 지원하기 위해 SCTP(Stream Control Transport Protocol)를 제공하는데, 데이터의 순차적인 전달을 비롯해 망 장애에 대비한 복구 기능을 수행할 수 있다.

시스템 성능 향상
커널 2.6부터는 프로세스의 문맥교환을 위한 부하를 감소시킴으로써 스케쥴링 확장성을 제공하는 저부하 스케쥴러(O(1) 스케쥴러)를 제공하여, 다음에 실행할 프로세스를 선택하는데 소요되는 시간이 프로세스의 수에 관계없이 일정하게 처리된다. 이와 함께 선점형 커널을 통해 최적의 스케쥴링을 제공할 수 있다. 하이퍼쓰레딩(Hyper-Threading) 혹은 SMT(Symmetric Multi-Threading)란 하나의 프로세서가 가상적으로 두 개의 프로세서처럼 동작하도록 하는 하드웨어 기술이다. 이 기술은 프로세서가 다수의 쓰레드를 동시에 각각의 프로세서에서 병렬적으로 실행되도록 함으로써 시스템의 성능을 상당히 향상시킬 수 있다. 하이퍼쓰레딩이 활성화되면 운영체제나 사용자의 관점에서 하나의 물리적 프로세서가 두 개의 프로세서로 보인다.

그러나 기존의 리눅스 커널은 하이퍼쓰레딩이 활성화된 프로세서에서 논리적인 두 개의 프로세서를 두 개의 물리적인 프로세서와 같이 취급했다. 즉, 스케쥴러는 논리적인 프로세서와 물리적인 프로세서를 구분할 수 없었다. 이것은 하이퍼쓰레딩 시스템에서 멀티프로세싱의 성능을 최대화하지 못하게 한다. 따라서 부요 서버에서는 하나의 물리적인 프로세서가 두 개의 작업을 처리하고 다른 물리적인 프로세서가 유휴 상태인 물리적인 프로세스의 불균형적인 문제와 하이퍼쓰레딩 환경에서 affinity를 고려하는 HT-aware 스케쥴러를 제공한다. 이 스케쥴러는 계산 위주의 작업, 입출력 위주의 작업 및 혼합형 작업의 벤치마킹 시험을 통해 안정적으로 시스템 성능을 유지시키는 것으로 판별되었다.

또한 프로세스가 실행될 프로세서를 지정하여 특정한 프로세서에서만 실행되도록 하는 process affinity 기능을 제공하는데, 응용 수준에서 사용할 수 있도록 sched_setaffinity, sched_getaffinity 시스템 호출도 지원한다. 메모리 관리 부분에서는 물리 주소를 가상 주소로 변환할 때 모든 페이지 테이블을 검색해야 하는 문제를 개선했으며, 최대 64GB 물리적 메모리와 가변 크기 페이지를 지원한다. 입출력 관리의 경우는 먼저 효율적인 입출력 성능 향상을 위해 기존의 인터럽트 방식에 의한 프로세서 간섭을 최소화하기 위해 인터럽트 방식과 폴링(polling) 방식을 혼합한 NAPI(New API) 인터페이스를 드라이버 개발자에게 제공한다. 이더넷 링크 통합은 분리된 물리적인 네트워크 카드를 논리적으로 통합하여 하나의 카드처럼 사용하도록 하는 기술로 높은 네트워크 대역폭 제공과 안정성을 강화할 수 있다. 통합된 링크들은 하나의 IP 주소와 MAC 주소를 사용한다. 또한 네트워크 성능 향상을 위해 더 큰 IP 프레임, 즉 최대 9,000바이트 크기의 MTU, 사용을 지원한다. 디스크 및 파일에 대한 비동기 입출력 지원과 최대 4096개의 디스크 연결 지원, 소프트웨어 스트라이핑(striping) 기능도 제공한다.

시스템 가용성 향상
부요 서버의 가용성 기능은 대부분 입출력 관리 기능에 해당된다. 앞에서 기술한 이더넷 링크 통합에 따른 네트워크 처리 대역폭 향상뿐만 아니라 일부 네트워크 카드 고장 시에 대기 중인 카드를 대체하여 장애를 극복한다. 이를 위해 동일 IP를 다수 네트워크 인터페이스에 할당하고, 드라이버는 지속적인 네트워크 상태를 감시하고 고장 시 자동으로 대체 인터페이스로 전환할 수 있는 기능을 제공한다. 소프트웨어 방식으로 미러링을 제공하는데, 일반적으로 특정한 컨트롤 카드를 이용한 하드웨어 방식의 미러링을 많이 사용하고 있다. 하지만 비용면에서 휠씬 유리하고 효율성이 좋은 소프트웨어 방식을 제공하므로써 일부 디스크 고장 시에도 모든 데이터를 복원할 수 있다.

CGL 규격 명세서 서버 사용 중에 저장 장치 공간의 부족 등과 같은 이유로 저장 내용의 변동없이 저장 공간의 크기를 변경할 수 있도록 권장하고 있다. 일반적으로 파티션의 크기를 정한 후에 파티션을 확장하려면 그 파티션의 내용을 삭제하고 새로운 파티션을 구성해야 하는데, 이 때 시스템 운영을 정지시켜야 한다. 따라서 이러한 요구사항을 반영하기 위해 논리 볼륨 관리 기능을 제공한다. 볼륨 관리자는 다수의 독립적인 저장 장치를 볼륨이라는 논리적인 하나의 대용량 저장 장치로 관리하여, 볼륨의 생성 등이 시스템을 재기동하지 않고 가능하도록 한다. 또한 시스템이 비정상적으로 재가동될 때 파일 시스템 무결성 검사 과정을 거치지 않고 빠르게 활성화될 수 있는 견고한 파일 시스템들을 지원한다. 입출력 장치에 핫스왑(Hot swap) 기능을 지원한다. CGL 규격 명세서에서는 주로 디바이스 장치에 대한 핫플러그(hot plug) 기능 지원을 요구하고 있으며, DCL의 경우는 메모리, 프로세서 등의 서버 핵심 하드웨어 요소에 대한 핫플러그 지원을 요구하고 있다. 현재 부요 서버에서는 부요 데스크탑과 마찬가지로 USB 장치에 대해서는 시스템 동작 중에 장치 추가·제거, 그에 따른 장치 드라이버 적재와 응용 동작이 자동으로 진행되고, 사용자에게 상태 통보 등의 전달 방식을 개발 완료했다.

소프트웨어 미러링을 통한 저장 장치의 데이터 가용성을 비롯해 저장 장치의 케이블, 버스 등의 하드웨어적인 고장에 대한 대비를 위해 multipath I/O를 지원한다. 즉 이 기능으로 저장 장치 접근 가용성을 높일 수 있는데, <그림 8>과 같이 사용자 수준의 도구와 커널 수준의 DM(Device Mapper) 기능을 구현해야 한다. 현재 이 기능을 사용하는 데는 별 어려움은 없지만, 입출력 path가 다운될 때 상태를 감지하고 대처하는데 다소 많은 시간이 소요되는 등의 개선 사항들이 존재하기 때문에 점차적으로 부요에서 반영할 예정이다.

부요 서버에서는 파일 시스템의 이상 또는 저장 장치의 문제 발생 시 파일시스템 상에 오픈 파일 또는 수행 태스크가 존재하는 상황에서도 그 파일시스템을 강제로 해제할 수 있는 기능을 제공한다. 커널 2.6에서 이 기능을 완전하게 제공하는 배포판이 없기 때문에 여기서 좀 더 자세히 기술하고자 한다. 수많은 파일 작업을 수행하고 있는 도중에 블럭 디바이스나 시스템을 업그레이드를 위해 잠시 파일시스템을 해제해야 한다면, 일반적으로 사용하는 umount는 정상 처리되지 못할 것이며, 사용자는 시스템 재가동 이외에는 다른 대안을 찾을 수 없을 것이다. 이 문제를 해결하기 위해 모든 파일시스템에 적용할 수 있는 force unmount 기능을 개발한다. 다음 4가지 경우 파일시스템 해제 시 기존의 umount는 해당 파일시스템이 busy 상태로 실패하게 된다.

◆ 오픈된 파일이 존재하는 경우
◆ 수행중인 태스크의 바이너리 파일이 존재하는 경우
◆ 태스크의 CWD(Current Working Directory)가 파일시스템 하의 위치로 설정되어 있는 경우
◆ Nested Mounting Filesystem이 존재하는 경우

 

각 경우마다 처리되어야 할 것은 다르지만 전체적인 흐름은 <그림 9>와 같으며 부요에서는 시스템 관리자를 위해 fumount 명령어를 제공한다.

향상된 편리성 제공
편리성 기능은 시스템을 관리하는 편리한 도구, 기능 및 환경과 개발자를 위한 디버깅 환경 등을 포함한다. 일관성 있는 장치 명명 기능을 제공하여 장치가 제거된 후 다른 버스, 슬롯 또는 어댑터에 재설치되더라도 장치명이 동일하도록 유지시켜 주는 persistent device naming 기능을 제공한다. 또한 심각한 손상을 초래한 시스템 이미지로부터 이전의 안정된 이미지로 복구할 수 있는 시스템 이미지 복구 기능을 제공하는데, 주기적으로 또는 운용상의 변경이 생기기 전 시점으로 안정적인 이미지를 관리하여 대처한다. <화면 2>는 시스템 이미지 복구 기능 GUI를 나타낸다.

CGL 규격 명세서에서는 시스템을 운영할 때 발생할 수 있는 원인 파악 분석과 커널 디버깅 기능을 요구하고 있다. 따라서 부요 서버에서는 GUI 기반으로 사용하기 편리하고 강력한 모니터링 및 추적(tracing) 기능을 가지고 있는 도구들을 점차적으로 개발, 이식하고자 한다. 현재까지 지원하고 있는 도구로는 시스템 덤프(dump) 발생 시 일반적인 디버거 사용 방법과 유사하게 명령을 입력하면서 커널 덤프 이미지에 대한 분석을 통해 시스템 다운 원인을 파악하는데 도움을 주는 LKCD(Linux Kernel Crash Dump) 기능을 제공한다. 또한 LKCD는 메모리, 디스크, 네트워크를 통해서 반드시 필요한 부분의 덤프 이미지만을 저장할 수 있으며 다음 시스템 부팅 때 그 내용을 보존한다. 리눅스 커널 디버깅 및 정보를 출력하는데 일반적으로 printk를 많이 사용하는데, printk 작성 후 커널을 컴파일한 다음에 재부팅해야 하는 불편한 점이 있다. 이 문제를 해결하기 위해서 dymanic probes 기능을 제공한다.

개념적으로는 일반적인 디버거의 breakpoint를 설정하는 방식으로 수행될 커널 루틴 주소를 등록할 수 있는 인터페이스를 제공한다. 커널 공간뿐만 아니라 사용자 공간에서도 이 기능을 사용할 수 있도록 인터페이스를 제공한다. 커널이 생성하는 메시지를 기록하여 시스템에서 발생하는 여러 상황들을 명확히 표현할 수 있도록 이벤트 로그(evlog) 기능도 제공한다. 물론 기존에 사용되던 syslog가 존재하긴 하지만, syslog의 체계적이지 못한 로깅 방식은 시스템 개발자나 관리자에게 필요한 정보를 충분히 제공하지 못하기 때문에 새로운 표준을 적용하고자 하는 것이다. 또한 커널 디버거도 지원하며, 소스코드 시험 빈도 정도를 확인할 수 있는 coverage 도구를 제공하여 파일별, 소스 라인별 수행된 정보를 HTML 파일을 생성하여 보여준다.

보안은 CGL 규격 명세서의 기본적인 보안 기능을 만족시킨다. 또한 보안 결함을 발견할 때마다 보안 패치를 적용하는 사후 대응식의 접근을 방지하기 위해 MAC(Mandatory Access Control) 방식의 SELinux(Security-Enhanced Linux) 기능을 제공한다. SELinux는 미국 NSA(National Security Agency) 주도로 이루어진 오픈소스 기반의 프로젝트로, 비교적 최근에 제품으로 활용되고 있지만 오랜 기간에 걸쳐 개발·검증됐다. 데비안, 수세, 레드햇, 젠투(Gentoo) 등의 주요 배포판에서 적용하고 있다.

SELinux 의 보안 정책은 시스템 내의 모든 프로세스가 제한된 도메인에서만 실행되도록 sandbox 개념을 구현한 것이다. 즉 각 프로세스는 자신 도메인에서 자신에게 주어진 최소한의 권한 내에서만 동작하고 다른 프로세스 도메인을 간섭할 수 없다. 따라서 악의적인 사용자에 의해 시스템이 해킹당했다 하더라도 그 피해는 해당 프로세스 내로 제한되고, 피해가 확산되지 않는다. 이러한 보안 정책 설정을 위해 RBAC(Role Based Access Control)와 TE(Type Enforcement)를 결합한 형태의 정책 설정과 여러 개의 정책 설정 파일을 설정해야 한다.

예를 들면 아파치 기반의 웹 서비스의 경우 웹 서비스를 위한 프로세스의 데이터 파일 접근에 대한 정의와 라이브러리 사용에 대한 규칙, 사용자의 접근 제어, 네트워크 포트 등의 접근 정의 등 웹 서비스가 이루어지기 위해 사용되는 서버 자원과 주체 등 모든 부분에 대한 보안 정책을 설정해야 한다. 이러한 보안 정책 파일로 생성된 바이너리 정책 파일은 명령어에 의해 커널에 로드된다. 따라서 SELinux는 기존의 보안 코드 패치 방식이 아닌, 규칙 설정 방식이다. 또한 SELinux의 커널 코드 부분은 기존 방식인 시스템 호출 수준에서의 보안 제어 방식이 아니라 커널 기능 중 보안 확인이 필요한 부분이 설정된 규칙 등에 부합되는지를 확인하기 위해 보안 모듈을 호출하는 방식으로 구현되어 있다.

차세대 클러스터링 기술인 서버 가상화
리눅스 서버 가상화 기술은 인프라 내의 모든 IT 자원을 공개 표준에 기반해 가상화된 자원으로 정의하고 자원 풀을 형성하여 통합 관리할 수 있도록 해준다. 또한 이렇게 가상화된 자원을 각 서비스에 동적으로 할당 혹은 반환하여 자원의 활용도를 향상시키고 가상의 컴퓨팅 환경을 구축할 수 있도록 해준다. 이러한 가상화 기술을 통해 인프라 내 시스템의 성능을 향상시키고 확장성과 안정성을 제공할 수 있다. 더욱이 인프라 내 시스템 자원의 활용도를 극대화시켜 시스템 관리 비용을 줄일 수 있다. 이러한 리눅스 서버 가상화 기술을 <그림 10>과 같이 효과적으로 구현함으로써 최종 사용자들은 물론이고 시스템 관리자들에게도 가상의 리눅스 환경(linux virtual environment)을 제공할 수 있다. 이 리눅스 서버 가상화 기술을 LiVE(Linux Virtual Environment)라고 한다. 부요 서버에서는 <표 3>과 같이 단계적으로 기술을 개발하고자 한다.

1, 2단계는 CGL 규격 명세서 중 리눅스 클러스터링 기능에 관한 것으로 고가용 scalability 클러스터이며, 3단계는 기업 컴퓨팅용의 그리드 시스템을 의미하며 차세대 컴퓨팅 모델인 유틸리티 컴퓨팅 환경, 즉 전기나 수도와 마찬가지로 자유롭고 쉽게 컴퓨팅 지원을 사용할 수 있는 환경의 핵심 기술을 확보하고자 한다. 현재의 부요 서버에서 제공되는 LiVE 기술은 LiVE-HA와 LiVE-C로 나누어진다. LiVE-HA는 시스템 전체의 가용성을 높이고 중단 없이 안정적인 서비스를 제공할 수 있는 HA 클러스터링 지원 기능이다. LiVE-C는 클러스터 내 모든 자원을 통합 관리하여 가상의 단일 시스템 이미지를 제공함으로써 사용자 편이성을 높이고 클러스터 시스템의 자원 활용도를 개선할 수 있는 클러스터 자원 가상화 기술이다.

LiVE -HA는 독립 소프트웨어 시스템으로 동작 가능하며 일반적인 HA 클러스터링을 지원할 수 있다. 또한 LiVE-HA는 LiVE-C의 고가용성을 위해 LiVE-C의 핵심 기반 소프트웨어로 포함될 수도 있다. 기존의 HA 클러스터링 방식과 LiVE-HA의 차이점으로는 primary/backup 기법과 cascading 기법의 문제점을 해결하고 장점을 결합한 cascading primary/backup HA 기법을 제공한 점이다. 따라서 패일오버(fail-over) 시간이 단축되어 전체 시스템의 가용성을 향상시킬 수 있다. LiVE-C 구성요소는 scalability 클러스터링 기능, 클러스터 프로비저닝(provisioning)과 관리 기능과 원격 설치 기능으로 구성된다. Scalability 클러스터링 기능은 오래 전부터 잘 알려져 있는 LVS(Linux Virtual Server)이기 때문에 여기서는 더 이상 언급하지 않는다. 클러스터 프로비저닝이란 클러스터 시스템(HW & SW)의 구축부터 시작하여 특정 서비스를 설치하고 실제로 서비스를 실행시키기까지 일련의 모든 과정을 통합 가상화하여 제공하는 것을 의미한다. 따라서 LiVE-C에서는 이러한 클러스터 프로비저닝을 위해 다음과 같은 기능을 제공한다.

◆ 클러스터 모델링 : 클러스터 내 자원의 통합 관리를 통해 각 구성 요소들간의 구성 데이터의 일관성 유지
◆ 설치부터 응용 서비스까지의 완전한 프로비저닝 지원 : OS조차 설치되지 않은 노드에서 시스템 이미지 설치 및 서비스를 위한 가상 서버 풀 구성 후, 현재 제공되고 있는 서비스와 모니터링 자료 등을 기반으로 추가된 노드가 담당한 서비스 구성

 

이러한 클러스터 프로비저닝은 표준화된 개방형 프레임워크를 지원함으로써 상호호환성을 높여 일관된 시스템 관리를 가능하게 하는 DMTF 표준을 근간으로 한다. 1992년 설립된 DMTF는 인터넷과 기업 환경에 대한 표준을 개발, 채택하고 상호 이용을 주도하는 기술 산업 조직으로서 멤버를 중심으로 워킹그룹을 형성하여 표준 규격을 정의하고 개발해 나가고 있다. DMTF에서 정의하고 있는 표준 중에 부요 서버와 관련되는 표준은 CIM, WBEM(Web-Based Enterprise Management)이며, CGL 규격 명세서에서도 요구 기능으로 이미 정의되어 있다. CIM은 시스템 자원 및 서비스 등의 관리 정보를 교환하기 위한 표준 모델이며, WBEM은 시스템 관리 응용, CIM 정보 전달자 등 간의 정보 표현 방식과 전달 방식에 대한 표준을 기술하고 있다.

LiVE -C의 마지막 기능은 원격 설치 부분으로 단순히 단일 시스템에서의 설치가 아니라 분산 혹은 클러스터 환경을 고려한 설치 방법을 제공한다. LiVE-C는 여러 노드를 위한 시스템 이미지를 생성하고, 하나의 클러스터 시스템을 구축함에 있어 다양한 정보들, 즉 사용자, 호스트, 서비스의 설정 파일들을 동기화하여 유지한다. 그리고 생성된 이미지로 네트워크의 설정을 통해 이미지를 사용하는 모든 서버 노드들에 자동 설치가 이루어진다. 또한 클러스터 환경에서 패키지 목록 조회, 정보 조회, 원격 패키지 설치 기능도 제공한다. 이러한 LiVE 기능들은 LAT(LiVE Administration Tool) 통합 관리 도구를 통해 사용할 수 있다.

부요 서버의 표준 기능 만족도와 성능
마지막으로 부요 시험에 대해 살펴보자. LSB2.0 표준 준수 여부 시험은 서버뿐 아니라 데스크탑에서 LSB runtime 시험슈트 2.0.6-2를 사용하여 진행됐다. 특히 부요 서버 경우는 기본 기능 시험과 고부하 지속 시험, 다양한 성능 시험이 이루어졌다. 기본 기능 시험은 시스템 호출 인터페이스를 통해 부요 커널의 기본 동작 상태를 시험하는 것으로, 공개 프로젝트인 LTP(Linux Test Project)의 시험슈트를 활용했으며 타 제품과 비교 결과 동일한 결과를 낳았다. 고부하 지속 시험은 모든 서버 자원을 고갈시키는 스트레스 부하 상태를 5일 동안 계속적으로 수행해야 시험을 통과하는 조건이다. 사용된 슈트는 기본 기능 시험 때와 마찬가지로 LTP 슈트를 사용했다.

마지막으로 성능 시험의 경우는 운영체제 성능, 웹 성능, 데이터베이스 성능, 파일전송 성능 등으로 이루어졌으며 타 제품과 유사한 결과를 낳았다. 이 글에서는 운영체제 성능에 대해 언급한다. 이 성능 시험은 다중 사용자 환경을 모델링하여 시스템에 부하를 가할 때 전체 시스템의 작업 처리량을 측정함으로써 시스템의 성능을 확인하는 방식의 AIM 멀티유저 벤치마킹 슈트를 사용했다. 2프로세서 및 4프로세서 시스템에서 커널 2.6 기반의 국외 제품인 수세, 레드햇과 비교 분석한 결과는 <그림 11>과 같다. 결론적으로 기본 기능 시험 및 고부하, 성능 시험 등을 통해 부요 규격이 국외 타 제품과 동등한 기능, 성능을 발휘함을 알 수 있었다.

한국 리눅스의 희망
지금까지 부요의 전반적인 스펙에 대해 자세히 알아보았다. 부요가 가야할 길은 아직 멀지만 충분히 좋은 결실을 얻었고 또 전망이 밝기 때문에 부요를 감히 한국 리눅스의 희망이라고 말할 수 있을 것이다. 부요의 향후 계획으로는 부요 플랫폼 기술을 기반으로 동북아시아 한·중·일 공개 소프트웨어 공통 핵심 기술 개발과 3국간 공통 표준플랫폼 개발에 점차적으로 참여를 강화하여 국제 커뮤니티에 기여하고, 글로벌 제품 개발에 노력할 것이다. 이제부터 리눅스 사용자와 개발자들의 지지와 충고가 본격적으로 필요한 시기이다. [MASO]

신고
Posted by 새우날다 Trackback 0 Comment 0

우분투리눅스에서 APM 설치하기.

먼저 아파치를 설치한다.

apt-get install apache2

이렇게하면 에러가 난다.

apache2: Could not determine the server's fully qualified domain name, using 127.0.0.1 for ServerName

그러면 /etc/apache2/apache2.conf를 열어 맨뒤에 ServerName localhost를 추가한다.

$ gedit /etc/apache2/apache2.conf

.............

ServerName localhost

이제 PHP를 설치한다.

apt-get install php5

다음으로 MySQL도 설치한다.

apt-get install mysql-server libapache2-mod-auth-mysql php5-mysql

MYSQL 루트 패스워드를 설정하자.

mysql -u root

mysql> SET PASSWORD FOR root@localhost = PASSWORD('패스워드');

Query OK, 0 rows affected (0.00 sec)

일단 설치는 끝났다.

이제 데이타베이스를 만든다.

mysql> CREATE DATABASE blog;

MYSQL사용자도 추가한다.

mysql> GRANT ALL PRIVILEGES ON *.* TO 사용자명@localhost IDENTIFIED BY '패스워드' WITH GRANT OPTION;

프롬프트에서 빠져나가자.

mysql> \q

다음번에 MYSQL을 사용하려면

mysql -u root -p  또는 mysql -u 사용자명 -p

이제 PHP와 MYSQL을 연동시키자.

$ gedit /etc/php5/apache2/php.ini

해서 ";extension=mysql.so"이 있는 줄에 가서 처음 ";"를 제거해 준다.

이제 아파치를 다시 시작하자.

/usr/sbin/apache2ctl start

또는

/etc/init.d/apache2 start

아파치를 종료할 때는

/usr/sbin/apache2ctl stop

아파치를 새로 시작할 때는

/usr/sbin/apache2ctl restart

과 같이 한다.

신고
Posted by 새우날다 Trackback 0 Comment 0

원문 링크 : Flash 9 in 64-Bit Firefox on Fedora 7

번역판 링크 : Flash 9 in 64-Bit Firefox on Fedora 7(번역판)


Flash 9 in 64-Bit Firefox on Fedora 7

This describes briefly how to get the Flash 9 plugin running in a 64-Bit Firefox on Fedora 7.

I was told that there is a [Korean translation] of this entry at the [Korean Linux Documentation Project].

Installing the Flash plugin

We use the [Macromedia repo] for the flash player. Copy the file [macromedia-i386.repo] to your /etc/yum.repos.d directory. Then type (as root)
yum install flash-plugin
to install the plugin.

Building nspluginwrapper

Now comes the "tricky" part. We use the [nspluginwrapper] to use the 32-bit version of the flash plugin in our 64-bit Firefox.

For this download the [source RPM] that I created based on the one that you can get on the nspluginwrapper website. I converted it to a more Fedora-style RPM. It could be that you have to do a
yum install /usr/include/gnu/stubs-32.h
to get the 32-bit glibc-devel installed (additionally to the 64-bit version!). Then rebuild the RPM with
rpmbuild --rebuild /nspluginwrapper-0.9.91.4-1.src.rpm
or just download the RPMs that I build ([nspluginwrapper-0.9.91.4-1.x86_64.rpm] and [nspluginwrapper-i386-0.9.91.4-1.x86_64.rpm]).

Installing nspluginwrapper

Install the two RPMs nspluginwrapper-0.9.91.4-1.x86_64.rpm and nspluginwrapper-i386-0.9.91.4-1.x86_64.rpm that you either build or downloaded from above and install them with
rpm -Uvh nspluginwrapper-0.9.91.4-1.x86_64.rpm nspluginwrapper-i386-0.9.91.4-1.x86_64.rpm

Enjoy Flash

That's itm you are set, about:plugins should now show the flash plugin and flash should work!
신고
Posted by 새우날다 Trackback 0 Comment 0