검색 엔진의 방문이 늘어나고 있군...

Posted
Filed under 프로그램과 명령어/서버와 서비스
참조1: RHEV 평가판 지침서
참조2: RHEV 설치 지침서
참조3: RHEV 매니저 릴리즈 노트
참조4: RHEV 3.0 on VMware Workstation 9

본 문서는 가상 머신에 RHEV 솔루션을 설치하고 연동하는 방법을 설명합니다.

1. 가입 및 평가판 신청
  1. 사이트에 가입하여 로그인 후 Evaluations & Demos 클릭. Red Hat Enterprise Virtualization Evaluation 클릭.
  2. 체험판 양식을 입력하면 메일로 섭스크립션 메일이 도착. 상단에 Subscriptions -> Your Subscriptions -> Active Subscriptions에서도 확인 가능.
  3. RHEV 외에 RHEL 자체도 필요하므로 다시 위 주소로 가서 Evaluations & Demos에서 Red Hat Enterprise Linux 30-Day Evaluation 클릭. 같은 방법으로 양식을 입력하여 30일 평가판 섭스크립션 받음.
2. 이미지 파일 다운로드
  1. 상단에 Products -> Our Products -> Red Hat Enterprise Virtualization -> Evaluations 클릭.
  2. 아래 '1. Download Red Hat Enterprise Linux 6 Server'에 있는 버튼을 클릭. Binary DVD를 다운받음.
  3. 다시 되돌아와 '2. Download Red Hat Enterprise Virtualization Hypervisor'에 RHEV-H Image를 다운받음.
3. RHEL 설치 및 네트워크 설정
  • Red Hat Enterprise Virtualization Manager를 설치하기 위해 먼저 가상 머신에 Red Hat Enterprise Linux를 설치한다.(RHEVM 혼자 요구하는 최소 램이 4기가이므로 그보다 높아야 한다.)
  • 설치 패키지를 선택하는 단계에서 기본 옵션인 Basic Server를 선택한다.
  • 기본 네트워크 설정은 system-config-network 명령어로 설정한다. RHEV를 사용하려면 도메인(FQDN)이 반드시 필요한데 hosts 파일을 설정하여 이를 우회할 수 있다.
  • 네트워크를 위와 같이 수동으로 설정했다면 /etc/sysconfig/network-scripts 디렉토리의 인터페이스 설정 파일(if-eth0)에서 onboot을 yes로 바꿔 서비스 시작시 바로 사용할 수 있도록 하자.
  • 설정했던 IP와 사용할 도메인 쌍을 hosts 파일에 추가한다.
4. RHN 등록 및 채널 추가 후 Red Hat Enterprise Virtualization Manager 설치
주의: 공식적으로 레드햇은 RHN 대신 RHSM(Redhat Subscription Manager)을 추천하는 것으로 보이나 RHEV 평가판 지침서에서 RHN을 사용하고 있기 때문에 그냥 RHN으로 처리.
  1. rhn_register 명령어로 RHN 등록을 한다. RHN 계정명과 패스워드를 입력한다.
  2. yum -y update 명령어로 패키지들을 업데이트 후 리붓을 한다.
  3. redhat의 customer portal 홈페이지에서 로그인을 한 후 Subscriptions -> RHN Classic -> Resistered Systems 선택 후 등록했던 시스템 이름을 클릭. Alter Channel Subscriptions 클릭.
  4. Software Channel Subscriptions에서 아래 채널들 선택(Additional Services Channels for Red Hat Enterprise Linux 6 for x86_64 아래 있는 것도 있음):
    - RHEL Server Supplementary (v. 6 64-bit x86_64)
    - Red Hat Enterprise Virtualization Manager (version.number x86_64)
    - Red Hat JBoss EAP (v 6) for 6Server x86_64
  5. yum -y install rhevm 명령어로 Red Hat Enterprise Virtualization Manager를 설치. rhevm-setup 명령어로 인스톨러 실행. 설치 중 중요한 사항은 아래와 같다.
    - 해당 서버의 80, 443 포트는 접근할 수 있는 상태여야 한다.
    - (ISO 도메인을 위한)공유에서 NFS 공유를 설정하도록 했다면 RHEVM이 설치되는 머신에서 공유가 시작된다.
    - 선택한 스토리지 종류가 데이터 센터와 클러스터를 생성할 때 쓰일 것이다. 그 후에 Administration Portal에서 스토리지를 추가할 수 있다.
5. Red Hat Enterprise Virtualization Hypervisor(RHEVH) 설치
  1. VMware에서 새로운 가상 머신을 생성하며 이때 'install the operating system later'를 선택.
  2. 시스템 스펙으로 2 CPU, 8 GB 램, 'LSI Logic SAS' SCSI 컨트롤러(중요), OS는 RHEL을 선택.
  3. 탐색기로 VM 파일이 저장된 곳으로 가서 vmx 파일에 아래의 줄을 추가.
    apic.xapic.enable = "FALSE"
  4. 같은 파일에서 vcpu.hotadd를 TRUE에서 FALSE로 변경.
    vcpu.hotadd = "TRUE" -> vcpu.hotadd = "FALSE"
  5. 가상 머신 설정에서 Processors 선택. 오른쪽의 Virtualization engine에서 밑에 두 가상화 옵션 체크.
  6. 레드햇 홈페이지에서 RHEV Hypervisor를 다운받아 그 이미지로 부팅.
  7. GRUB 창에서 tab을 눌러 부팅 옵션 수정에 들어가 quiet를 제거하고 엔터를 눌러 설치.


  위의 과정을 모두 거치면 일단 웹 관리 포탈에 접속할 수 있습니다. 하지만 스토리지 도메인 설정이 되어 있지 않기 때문에 아직 정상적인 사용은 불가능합니다. 이후 본격적인 내용은 위 참조1의 평가판 지침서를 참조하시기 바랍니다.

2014/02/07 15:00 2014/02/07 15:00
Posted
Filed under 시스템
관련 링크: Mesa (computer graphics)
관련 링크: Direct Rendering Infrastructure
관련 링크: Gallium3D

  리눅스 게이밍이 떠오르는 요즘, 많이 보이는 관련 용어들에 대해 간단히 알아봤습니다.

리눅스 그래픽 스택

Mesa: OpenGL 구현하기 위한 프리&오픈 소스 라이브러리와 하드웨어 가속 3D 렌더링, 3D 컴퓨터 그래픽, GPGPU와 관련된 API의 모음집. API + DRI(Direct Rendering Infrastructure) + Gallium3D로 구성.

DRI(좌) vs Gallium3D(우)

DRI(Direct Rendering Infrastructure): X 윈도우 시스템에서 사용자 프로그램의 데이터가 디스플레이어 서버를 거치지 않고 비디오 하드웨어에 직접 접근하는 것을 안전하게 허용하기 위해 사용하는 인터페이스 및 자유 소프트웨어 기능.

DRM(Direct Rendering Manager): 비디오 하드웨어를 지원하기 위한 DRI 아키텍쳐를 구현하는 하드웨어에 의존적인 커널 모듈.

Gallium3D: 그래픽 디바이스 드라이버를 3개의 파트로 나눔으로서 3D 그래픽 칩셋을 위한 디바이스 드라이버 프로그래밍을 쉽게 만든 프레임워크.

fglrx: AMD GPU용 독점 드라이버 이름. 정확한 이름은 libGL-fglrx-glx. 참고로 NVIDIA GPU용 독점 드라이버 이름은 그냥 libGL-nvidia-glx.

nouveau: NVIDIA GPU용 오픈 소스 드라이버(정확히는 DRM) 이름. 정확한 이름은 libDRM-nouveau. 참고로 AMD GPU용 오픈 소스 드라이버 이름은 libDRM-radeon이고, Intel 내장 그래픽 칩셋용 오픈 소스 드라이버 이름은 libDRM-intel.


  AMD는 자사의 GPU를 위한 드라이버의 소스를 오픈 소스로 공개했습니다. 다만 독점 드라이버도 계속 내놓고 있는 걸 봐선 독점 드라이버의 소스를 그대로 공개한 것 같진 않습니다. 그런데 재미있는 점은 성능에서 Gallium3D의 오픈 소스 드라이버가 독점 드라이버를 앞지른다는 겁니다. 대체 뭘 하는 거냐 AMD...

  NVIDIA는 소스를 공개하고 있지 않습니다. 그래서 nouveau도 순전히 리버스 엔지니어링에 의존하고 있었습니다. 그러던 올해 9월, 자신들을 향한 리눅스 커뮤니티의 비난(+리누스 토발츠의 fxxk you 사건)이 신경쓰였는지 GPU 프로그래밍 문서를 공개했습니다. NVIDIA가 소스를 공개하고 있진 않지만 적어도 독점 드라이버의 성능에 있어서는 칭찬하지 않을 수 없습니다. 윈도우에서의 OpenGL 지원도 AMD와 비교했을 때 언제나 월등했고 결국 그게 리눅스에서도 결실을 맺은 겁니다.

  한편, AMD는 'Mantle'이라는 게임 그래픽 API를 독자적으로 개발하는 중이며 이를 통해 큰 퍼포먼스 상승을 노리고 있습니다. 일단은 멀티 플랫폼이고 리눅스에서도 뛰어난 성능을 발휘할 거라고 광고하고 있긴 한데...그 이전 문제로 신기술임과 동시에 AMD의 GPU만을 위한 기술이라 이런 단점을 감수하면서까지 Mantle을 도입할 개발사는 그리 많지 않을 것이라는 게 제 생각입니다.
2013/12/19 21:56 2013/12/19 21:56
Posted
Filed under 취미 및 잡담
원문: https://www.facebook.com/justinkyoon/posts/388867007862256

  저도 평소부터 높은 사람일수록 더 많은 책임과 의무가 따라야 한다고 생각했었고 또 실제로 군대에서도 그렇게 행동했었던지라 공감가는 바가 커서 옮겨왔습니다.


2010년 1월 오늘보다 더 심하게 눈이 왔던 날이 있었다.
한국군과 미국군의 상반된 지침이 꽤나 충격으로 다가온 날이었다.

한국군의 지침.
- 병사: 전원 출근
- 부사관: 근속년수 10년 이하 출근.
- 장교: 소령(진)까지 출근. <- 이 기준을 놓고 많은 논의가 있었다.
- 장군: 출근하지 않고 대기.
- 상황 발생하면 보좌관-비서실장 거쳐 장군에게 연락할 것.
- 각 부서에 전화대기 인원 확인되면 알아서 출근시간 조정.
(병사가 짱박혀있는 부서인 경우, 나머지 사람은 오후에 오겠다는 뜻.)

미국군의 지침.
- 장군: 전원 출근. 반드시 자가 차량으로 직접 운전하여 출근.
- 장교: 대령급(대령 + 부서 총책임자) 출근.
- 부사관: 주임원사 자가차량 출근. / Duty인 인원만 출근.
- 병사: 출근하지 않고 대기.

아무튼 두 국가간 이렇게 상반된 지침때문에,
우리 사무실에서는 한국군 쪽에는 병장인 나 혼자,
미국군 쪽에는 대령 혼자 전화대기를 했다.

서로가 서로의 상황을 어색해하다가 너무 궁금해서 내가
그 미군 대령한테 물었다.
미군 대령의 대답은 진짜 소름끼치게 멋있었다.


: 왜 미국군은 대령급 이상만 출근하는 것입니까?

미군 대령
: 계급(Rank)이 높을 수록 권한과 책임이 많아 의사결정의 범위가 넓으니까.
다시 말해, 지금 당장 긴급한 일이 터지면 너네쪽은
너가 행정담당관한테 말하고 행정담당관이 보좌관한테 말하고
보좌관이 비서실장한테 말하고 비서실장이 장군한테 말한후에,
장군이 무엇인가를 결정하면 다시 비서실장이 보좌관에게
보좌관이 행정담당관에게 행정담당관이 너에게 전달해서 조치가 되겠지.

근데 우리쪽은 내가 알아서 결정하고, 장군한테 보고하면 끝이거든.
결론이 좋게 나든 나쁘게 나든 책임은 내가 지면 되고.
사건 터지면 신속하고 올바르게 처리하는 것이 미군의 대응방식이야.
경험과 실력을 바탕으로 더 좋은 의사결정을 더 빨리 할수 있다는 것,
그게 우리가 생각하는 보다 높은 계급(Higher Rank)의 참된 의미야.

난 종종 면접가서 리더십과 관련된 질문을 받으면
이 에피소드를 말하는데, 많은 국내기업 면접관들이
'저게 뭔 소리야 - 아랫짬이 뺑이 쳐야지.' 하는 표정으로 날 보는게 싫다.

2013/12/15 04:19 2013/12/15 04:19
Posted
Filed under 취미 및 잡담
링크: Valve, SteamOS Beta 공개
본문: http://store.steampowered.com/steamos

스팀OS의 첫 베타 버전이 공개됐습니다. 아래는 본문에 대한 번역입니다.


  저희가 약속한 사용하기 편하고 강력하고 공개된 거실 엔터테인먼트 환경의 새 주자를 전해드리기 위해 열심히 작업했습니다.

  스팀OS 베타를 여러분이 사용할 수 있게 함으로써 우리의 목표에 한 걸음 크게 다가갔다는데 기쁨을 느끼고 있습니다. 다만 이것에 참여하시기 전에 스팀OS 베타가 무엇이며 지금 지원되지 않는 것이 무엇인지 반드시 숙지해주시길 부탁드립니다.



스팀OS 베타가 무엇인가요?
  스팀OS 베타는 우리의 리눅스 기반 운영체제로서 이번에 처음 여러분께 공개됐습니다. 기반 시스템은 데비안7(코드 네임 Debian Wheezy)을 사용합니다. 우리의 작업물은 견고한 데비안 코어 위에 설치되어 있으며 그것을 거실에서 사용하는 것에 최적화시켰습니다. 무엇보다도 이것은 공개된 리눅스 플랫폼으로서 여러분에게 완벽한 제어권을 제공합니다. 여러분은 자신의 시스템에서 모든 권리를 행사할 수 있으며 여러분이 원하는 새로운 소프트웨어나 컨텐트를 설치할 수 있습니다.



지원되지 않는 것은 무엇인가요?
  아직 초기 단계이기 때문에 많은 것이 수정되고 있으므로 조잡한 상태입니다. 현재로선 기술자가 아닌 사용자가 사용하기에 절대적으로 충분치 않습니다.

  가장 중요한 사항이 있는데 지금은 특정한 하드웨어들(FAQ를 참조)만 지원하고 있다는 겁니다. 우린 이 목록을 늘리기 위해 노력 중입니다.

  일단 우리는 이미 이걸 우리의 거실에 사용하고 있습니다. 이것 그 자체와 앞으로 어떻게 변모할 것인지를 즐기고 있죠. 그리고 많은 분들이 그렇게 느끼며 우리에게 여러분이 느낀 점을 알려주신다면 제품의 완성은 더 빨라질 겁니다.

  여러분들은 스팀OS를 데스크탑 운영체제의 대체제로 생각해선 안 됩니다. 스팀OS는 거실에서 사용하도록 고안됐으며 또 그렇게 최적화돼 있습니다.



스팀OS 베타에 포함된 모든 것이 오픈 소스 소프트웨어인가요?
  아닙니다. 스팀OS 베타에는 우리의 스팀 클라이언트 프로그램과 타사의 드라이버가 포함되어 있으며 이들은 독점 소프트웨어입니다. 스팀OS 베타의 표준 설정을 이용한다면 스팀 클라이언트 프로그램은 유저 인터페이스와 우리의 스팀 온라인 서비스에 대한 접근성을 제공합니다. 그렇다고 해도 여전히 여러분은 표준 리눅스 데스크탑을 사용하실 수 있습니다.



스팀OS의 소스 코드는 어디서 받을 수 있나요?
  스팀OS는 스팀OS 머신에 들어갈 소프트웨어를 관리하기 위해 Advanced Packaging Tool 시스템(APT)을 사용하고 있습니다. 스팀OS의 APT 저장소는 이곳입니다.


  아래는 FAQ에 있는 내용입니다.


Q: 스팀OS란?
  스팀OS데비안 GNU/Linux의 파생 OS입니다. 첫 버전(스팀OS 1.0)은 'alchemist'라고 칭하며 데비안 'wheezy'(stable 7.1) 배포판을 기반으로 합니다.
  스팀OS로 인한 주요 변경점은 다음과 같습니다.
  (1) Debian testing으로부터 eglibc 2.17을 백포트함
  (2) 다양한 타사의 드라이버 추가 및 업데이트된 그래픽 스택(Intel과 AMD 그래픽 지원은 향후 예정)
  (3) 업데이트된 3.10 장기 분기점 커널 트래킹(현재 3.10.11)
  (4) 스팀, 게임, 스팀OS 간의 부드러운 전환을 위한 커스텀 그래픽 컴포지터
  (5) 밸브 스팀OS 저장소를 이용한 자동 업데이트 설정

Q: 스팀OS의 하드웨어 요구사항은?
  (1) Intel 또는 AMD 64비트 지원 프로세서
  (2) 4기가 이상의 램
  (3) 500기가 이상의 디스크
  (4) NVIDIA 그래픽 카드(AMD와 Intel은 향후 지원 예정)
  (5) UEFI 부트 지원
  (6) 설치를 위한 USB 포트

Q: 스팀OS는 오픈 소스인가?
  기본 운영체제 컴포넌트는 오픈 소스입니다. 스팀 클라이언트 자체와 타사의 독점 드라이버들은 독점 소프트웨어입니다.

Q: 스팀OS의 소스는 어디 있는가?
http://repo.steampowered.com/steamos

Q: 스팀OS에서 수정사항이나 새로운 기능은 어떻게 받는가?
  모든 스팀OS 머신은 정기적으로 표준 데비안 APT 패키지 매니저를 사용해 밸브의 공개 저장소로부터 자동 업데이트를 하도록 설정되어 있습니다.

Q: 스팀OS에서 어떤 소프트웨어가 돌아가는가?
  스팀OS는 스팀과 스팀 게임이 돌아가도록 되어 있습니다. 또한 일반 리눅스 프로그램을 실행할 수 있는 데스크탑 모드도 제공합니다. 소프트웨어 업데이트에 표준 APT 패키지 매니저를 사용하기 때문에 사용 저장소에 다른 저장소를 추가하여 더 많은 프로그램을 설치 및 사용할 수 있습니다. 현재 스팀OS 자체로는 소량의 패키지들만 제공하고 있지만 수많은 데비안 wheezy 패키지가 스팀OS에서 잘 작동합니다. 향후엔 다양한 패키지를 스팀OS 저장소에서 직접 제공할 계획입니다.

Q: 데비안은 무엇인가? wheezy는 또 뭔가?
  데비안은 리눅스 운영체제의 한 배포판으로서 자세한 것은 이곳에서 볼 수 있습니다. Wheezy는 현재 데비안의 안정화 버전명으로 스팀OS 배포판도 그것을 사용하고 있습니다.

Q: 밸브는 일반 리눅스 데스크탑으로 우분투를 추천했었다. 왜 스팀OS는 우분투가 아닌 데비안을 기반으로 만들었나?
  데비안 코어 위에 만드는 것이 우리 고객에게 완벽히 최적화한 스팀OS를 전할 수 있는 최선의 방법이기 때문입니다.(역자 주: 우분투도 데비안 기반입니다.)

Q: 스팀OS에서 마이크로소프트 윈도우즈 게임과 프로그램들을 실행할 수 있는가?
  불가능합니다. 스팀OS는 데비안 GNU/Linux를 기반으로 하고 있으며 마이크로소프트 윈도우즈 게임 및 프로그램들과 호환되지 않습니다. 하지만 스팀OS는 빠른 시일 내에 당신의 윈도우즈 컴퓨터에서 당신의 게임들을 쾌적하게 스트리밍하는 것을 지원할 것입니다. In-Home Streaming Beta에 관한 자세한 정보는 이 페이지를 확인하시기 바랍니다.

Q: 스팀OS의 업데이트 주기는 어떻게 되는가?
  보안 패치와 치명적인 버그 패치는 최대한 빨리 할 것입니다. 배타 업데이트 채널은 매일이나 매주 정기 패치를 할 것이며 이렇게 수행한 업데이트들을 몇 달에 한 번씩 일반 채널에 배포할 겁니다. 우리는 이제 막 최선의 방법하기 모색하기 시작했으며 릴리즈 방식은 향후에 더 다양해질 수 있습니다.

Q: 스팀OS는 어떻게 설치하나?
(괜히 따라하시면 시스템을 날리실 수 있으므로 번역하지 않겠습니다.)

Q: 스팀OS에서 데스크탑은 어떻게 이용할 수 있나? 보이는 게 스팀뿐이다.
  스팀OS 데스크탑을 이용하려면 스팀 설정 메뉴에서 활성화를 해야 합니다. Settings(우측 상단의 기어 아이콘)을 선택한 후 Interface를 선택하고 "Enable access to the Linux desktop" 박스를 체크합니다. 이제 Exit 버튼에 "Return to Desktop"이라는 추가 옵션이 생기고 이를 통해 스팀OS 데스크탑으로 전환할 수 있습니다.

Q: 스팀OS 계정은 어떻게 설정되어 있는가?(역자 주: 스팀이 아닌 OS 계정을 뜻합니다.)
  스팀OS에는 미리 만들어진 계정이 2개 있습니다. 첫 번째는 "steam"으로 스팀과 게임들을 실행하기 위한 계정입니다. 이 계정은 관리자 권한이 없는 계정입니다. 두 번째는 "desktop"으로 스팀OS 데스크탑과 스팀과 관련이 없는 프로그램을 실행하기 위한 계정입니다. 이 계정은 패스워드 설정 후 'sudo' 명령어를 통해 관리자 권한을 획득할 수 있습니다.

  참고로 이것은 스팀OS 계정에 대한 설명으로 스팀 로그인과는 아무 관계가 없습니다. 여러분은 여러 스팀 사용자로 로그인할 수 있지만 현재로선 그 모든 사용자가 같은 스팀OS 데스크탑 및 계정들을 공유합니다.

Q: 스팀OS에서 root 권한을 사용하려면 어떻게 해야 하는가?
  데스크탑 계정은 root 권한을 사용할 순 있지만 기본적으론 패스워드가 설정되어 있지 않습니다. root 권한을 사용하려면 그 전에 패스워드부터 설정해야 합니다. 데스크탑 세션에서 터미널 윈도우를 열고 'passwd' 명령어를 실행합니다. 새로운 패스워드를 2번 입력합니다. 이제 'sudo' 명령어를 통해 관리자 권한이 필요한 작업을 할 수 있습니다.

Q: 나는 하드웨어 베타 참가자다. 스팀OS에 대한 지원은 어떻게 받을 수 있는가?
  스팀 머신을 가지고 계시다면 공개 밸브 버그 트래커의 계정을 생성할 수 있는 초대장을 email로 받으셨을 겁니다. 이 계정을 만들면 스팀OS 데스크탑에서 사용이 가능한 밸브 버그 리포터 프로그램을 이용할 수 있습니다. 버그에 대한 상세 내역을 작성하려면 스팀OS에 키보드를 연결해야 합니다. 또한 Win+B 단축키를 눌러 밸브 버그 리포터를 실행할 수 있습니다. 이 단축키를 사용하면 스크린샷을 첨부해주기 때문에 스팀이나 게임의 버그를 리포팅할 때 매우 유용합니다.

  어떤 이유로 인해 밸브 버그 리포터를 사용할 수 없다면 아무 웹 브라우저에서 버그 리포터로 직접 접속할 수 있습니다.

Q: 스팀OS가 오작동을 한다. 어떻게 하면 복구할 수 있나?
  표준 스팀OS 설치본은 하드 드라이브에 복구 파티션을 포함하고 있습니다. 이 파티션을 이용해서 시스템 드라이브를 원래의 상태로 복구할 수 있습니다. 여러분의 스팀 설치본, 게임, 데스크탑 변경사항은 그대로 남을 겁니다. 복구 파티션을 사용하려면 스팀OS 머신에 키보드를 연결해야 합니다. 머신을 껐다 켜고 시스템이 시작됐을 때 ESC키를 계속 누르면 스팀OS 부트 메뉴가 나옵니다. 메뉴에서 "Restore System Partition"을 선택합니다. 시스템이 시작되고 여러분에게 확인을 물을 겁니다. 시스템 디스크를 복구 후 스팀OS로 돌아가게 됩니다.

  만약 이 방법으로도 문제를 해결하지 못한다면 동봉된 USB 복구 디스크를 사용해야 합니다. 이 방법을 사용하면 하드 드라이브가 완전히 밀리며 머신은 공장 초기화 상태가 됩니다. 모든 스팀 게임이나 데스크탑 변경사항은 사라집니다. 복구 디스크를 사용하려면 스팀OS 머신에 키보드를 연결 후 머신을 껐다 켜고 시스템이 시작됐을 때 F11키를 누르면 펌웨어의 "Select Boot Device" 메뉴에 진입할 수 있습니다. 여기서 첫 번째 항목인 "UEFI:Centon Centon USB 8.07"을 선택하면 스팀OS 복구 디스크 부트 메뉴에 들어오게 됩니다. 메뉴에서 "Restore Entire Disk"를 선택합니다. 당신의 머신은 완벽히 재설치될 겁니다. 작업이 끝나면 머신이 꺼집니다. 머신을 켜서 스팀OS로 돌아갑니다.

Q: 스팀OS가 내 하드웨어를 지원하지 않는다. 새로운 그래픽 드라이버와 칩셋 드라이버는 어떻게 설치하나?
  스팀OS용 드라이버는 시스템 이미지의 일부로 제공되며 밸브에 의해 결합됩니다. 밸브는 시간이 지남에 따라 새롭거나 업데이트된 드라이버를 결합시킬 예정입니다. 새로운 드라이버를 설치하는 절차는 데비안의 다른 배포판과 다르지 않거나 또는 밸브가 새로운 드라이버를 리패키지하여 재배포할 겁니다. 만약 일반 사용자가 이미 존재하는 스팀OS 설치본에 새로운 드라이버 패키지를 설치하길 원한다면 우리는 데비안 패키징 방식과 큰 호환성을 갖추도록 할 예정입니다.

Q: 우리한테 우분투용으로 개발한다고 하지 않았었나? 스팀OS를 구축하기 위해 데비안을 설치할 필요가 있는가?
  모든 스팀 프로그램은 스팀 런타임(리 눅스 프로그램을 위한 수정된 바이너리 호환 레이어)을 사용하여 실행합니다. 이로 인해 스팀 런타임을 지원하는 모든 리눅스 배포판에서 재컴파일 없이 프로그램을 실행할 수 있습니다. 여러분의 개발환경이 스팀 런타임을 포함한 우분투 12.04 LTS라면 별도의 변경 없이 실행할 수 있습니다. 당신이 스팀 파트너라면 리눅스와 스팀OS용 스팀 프로그램 제작에 대한 자세한 내용은 리눅스 개발 페이지를 참조하시기 바랍니다.


  이번에 공개된 버전은 일반적인 리눅스 배포판과 다르게 수동 파티셔닝을 기본적으로 제공하지 않는 것으로 보입니다. 설치 방법으로 두 가지가 소개되어 있는데 둘 모두 하드를 싹 날리고 새로 설치합니다. 또한 NVIDIA 카드만 지원하므로 가상화 솔루션으로 테스트는 불가능할 것 같습니다. 따라서 하드웨어 요구사항에 만족하면서 잉여로 놀고 있는 PC를 가지고 계시거나 싹 밀어도 상관 없으신 분이 아니시라면 향후 정식 버전이나 다른 사람들에 의해 수동 파티셔닝이 가능하게 개조된 버전이 나오는 것을 기다리시는 것이 좋을 것 같습니다.
2013/12/14 15:08 2013/12/14 15:08
Posted
Filed under 시스템
참조 원문: Life cycle of a process

  시스템에서 뭔가를 하려면 프로세스가 필요합니다. 프로세스는 일반적으로 바이너리 실행 프로그램을 실행했을 때 생성됩니다. 코드가 프로세스로 변환되는 과정, 프로세스가 생성되는 방법, 죽기 전까지 거치는 상태를 이해하는 것은 상당히 중요합니다. 이 글에서는 코드가 실행 파일이 되고 거기서 다시 프로세스로 되는 과정, 프로세스와 관련이 있는 식별 요소들, 프로세스의 메모리 구조, 프로세스의 상태, 리눅스 내에서 프로세스의 전체적인 라이프 사이클에 대한 요약을 알아볼 것입니다.

코드에서 실행 프로그램으로
  소프트웨어 프로그램의 생명은 개발자가 코드를 작성할 때부터 시작됩니다. 여러분이 사용하는 모든 소프트웨어 프로그램은 특정 프로그래밍 언어로 작성됐습니다. 코드 작성이 끝나면 다음 단계로 그것을 실행 프로그램으로 변환합니다. 컴파일 프로세스가 코드를 기계 수준의 명령어(실행 프로그램)로 변환하죠. 그러면 실행 프로그램은 OS가 이해할 수 있는 기계 코드를 갖게 됩니다.

실행 프로그램에서 프로세스로
  프로그램이 실행되면 ps 명령어로 관련 프로세스를 확인할 수 있습니다. 리눅스에서 프로세스와 관련된 주요 식별 요소는 3가지로 프로세스 ID, 부모 프로세스 ID, 그룹 ID가 있습니다.

  init이란 프로세스는 리눅스 시스템에 생성되는 첫 번째 프로세스이며 프로세스 ID는 1입니다. 다른 모든 프로세스는 init의 자식 또는 그 이하입니다. pstree 명령어를 사용하면 활동 중인 프로세스들을 계층 구조로 볼 수 있습니다.

리눅스 프로세스의 메모리 구조
  리눅스 프로세스의 메모리 구조는 아래의 메모리 세그먼트들로 이뤄져 있습니다.

Stack: 지역 변수와 함수 인자(프로그램 코드에 정의되어 있음)가 있는 세그먼트입니다. 이 안에 있는 내용은 LIFO(last in, first out) 순서로 저장됩니다. 함수가 호출되면 새로운 함수와 연관된 메모리는 stack에 할당됩니다. 필요할 경우 메모리가 동적으로 증가하지만 일정한 수준까지만 가능합니다.

메모리 맵핑: 이 영역은 맵핑 파일을 위해 사용합니다. 이것이 존재하는 이유는 메모리에 맵핑된 파일에 대한 입출력 작업은 (일반적으로 파일이 저장된 곳인)디스크에 대한 입출력과 비교했을 때 프로세서(CPU)와 시간을 별로 소모하지 않기 때문입니다. 그렇기 때문에 이 영역은 거의 대부분 동적 라이브러리를 위해 사용합니다.

Heap: Stack에는 2가지 제한이 있습니다. 크기가 그리 넉넉치 못하다는 것과 stack을 생성한 함수가 종료되거나 값을 반환할 때 stack의 모든 변수도 사라진다는 겁니다. 이런 점에 있어서 heap 메모리 세그먼트가 빛을 발합니다. 이 세그먼트를 통해 매우 큰 메모리를 할당할 수 있으며 이렇게 할당한 메모리는 프로그램이 끝날 때까지 사용할 수 있습니다. 그러므로 heap에 할당한 메모리는 프로그램이 종료되거나 프로그래머가 함수 호출을 통해 명시적으로 해제하기 전까지 해제되지 않습니다.

BSS와 데이터 세그먼트: BSS 세그먼트에는 최초에 명시하지 않은 정적/전역 변수를 저장하며, 데이터 세그먼트에는 값을 최초에 명시한 변수를 저장합니다. 참고로 전역 변수란 함수 안에 정의되어 있지 않으며 프로그램과 스코프/라이프타임이 동일한 변수를 말합니다. 유일한 예외는 함수 안에 있지만 static 키워드로 정의된 변수로서 그 스코프는 함수 내로 제한됩니다. Static으로 정의된 변수들은 BSS 또는 데이터 세그먼트에 전역 변수들과 함께 저장합니다.

텍스트 세그먼트: 프로세서가 읽고 실행할 프로그램의 모든 기계 수준 코드 명령어를 보관하고 있습니다. 이 세그먼트는 쓰기 보호가 되어 있어서 수정이 불가능합니다. 만약 그런 시도를 하면 crash나 segmentation fault가 발생합니다.

참조: 실제 메모리 구조는 위의 내용보다 더 복잡하지만 이 정도만으로도 개념을 잡기엔 충분합니다.

리눅스 프로세스의 상태
  리눅스에서 프로세스를 실시간으로 관찰할 때는 top 명령어를 사용합니다. 이 명령어의 8번째 칼럼에는 프로세스의 상태가 적혀 있습니다. 여기에 나오는 용어의 뜻을 이해하는 것은 매우 중요합니다. 리눅스의 프로세스는 다음 중 하나의 상태에 놓입니다.

Running: 프로세스가 실제로 실행되고 있거나 실행되기 위해 스케줄러의 큐에서 대기 중(실행 준비 완료)인 상태입니다. 때문에 경우에 따라 'runnable'이나 R로 표시하기도 합니다.

Waiting 또는 Sleeping: 어떤 일을 발생하는 것을 기다리거나 완료를 위해 특정 리소스가 필요한 작업을 위해 기다리는 상태입니다. Waiting 상태는 상황에 따라 interruptible(S)과 uninterruptible(D)로 나눠지기도 합니다.

Stopped: 멈추라는 신호를 받은 상태입니다. 일반적으로 디버그를 할 때 볼 수 있습니다. 이 상태는 T로 표시합니다.

Zombie: 실행은 끝났지만 부모가 종료 상태를 회수하기 전까지 기다리는 상태입니다. 이 상태는 Z로 표시합니다.

  위 상태들이 끝나면 프로세스는 죽습니다. 정확히 따지자면 죽은 프로세스는 존재 자체가 사라지므로 '죽음'이란 상태는 없습니다.

프로세스의 라이프 사이클
  프로세스는 생성되는 순간부터 종료되기(또는 kill 당하기)까지 다양한 단계를 거칩니다. 여기서는 리눅스 프로세스의 탄생부터 죽음까지의 라이프 사이클 전체를 설명합니다.

  리눅스 시스템이 처음 켜지면 압축된 커널 실행 코드가 메모리에 적재됩니다. 이 실행 코드가 리눅스 시스템의 다른 모든 프로세스를 생성하는 것에 대한 책임을 지는 init 프로세스(또는 시스템의 첫 프로세스)를 생성합니다.

  Running 프로세스는 자식 프로세스를 생성할 수 있습니다. 자식 프로세스는 fork() 함수나 exec() 함수(exec() 함수는 어떤 실행 파일을 실행시키고 그로 인해 생긴 프로세스를 자신에게 덮어씌우는 함수로 자식 프로세스를 생성하는 함수가 아님)로 생성할 수 있습니다. 만약 fork()를 사용하면 해당 프로세스는 부모 프로세스의 주소 공간을 사용하며 부모와 같은 모드에서 실행됩니다. 새롭게 탄생한 (자식)프로세스는 부모로부터 모든 메모리 세그먼트를 복사해서 물려받지만 (부모나 자식이)세그먼트를 수정하려고 하기 전까진 계속해서 같은 세그먼트를 사용합니다. 이에 반해 exec()를 사용하면 프로세스에 새로운 주소 공간이 할당되므로 처음에는 커널 모드에 진입합니다. 참고로 부모 프로세스가 새로운 프로세스를 생성하려면 running 상태(이면서 프로세스에 의해 실제로 실행 중인 상태)여야 합니다.

  커널 스케줄러의 상황에 따라 다른 프로세스가 CPU를 선점하면 그 전에 CPU를 사용하던 running 프로세스는 큐로 쫓겨나 다시 실행되기 전까지 대기하게 됩니다.

  만약 프로세스가 하드웨어 리소스를 확보하거나 파일 입출력 작업을 할 필요가 있다면 프로세스는 일반적으로 시스템 콜을 하여 커널 모드로 진입합니다. 만약 리소스가 이미 사용 중이거나 파일 입출력에 시간이 걸린다면 프로세스는 sleeping 상태로 들어갑니다. 리소스를 사용할 수 있거나 파일 입출력이 끝나면 프로세스는 '프로세스를 깨우는 신호(signal)'를 받고 일어나 커널 모드로 실행을 계속하거나 유저 모드로 되돌아갈 수 있습니다. 참고로 그 프로세스가 즉시 실행을 시작할 것이란 보장은 없으며 그것은 순전히 (실행 준비를 위해 프로세스를 프로세스 큐에 넣는)스케줄러에 달려 있습니다.

  만약 프로세스를 디버그 모드(예: 디버거가 프로세스에 부착됨)로 실행하면 디버그 프레이크포인트를 만났을 때 정지 신호를 받습니다. 이 단계에서 해당 프로세스는 stop 상태에 들어가며 유저는 프로세스의 메모리 상태, 변수 값 등을 가지고 디버그할 시간을 갖게 됩니다.

  프로세스가 정상적으로 값을 반환하거나 종료될 수도 있고 다른 프로세스에 의해 죽을 수도 있습니다. 어느 쪽이 됐든 간에 프로세스는 zombie 상태에 빠지게 되며 그렇게 되면 그 프로세스에 대한 것들 중 (커널에 의해 관리되는)프로세스 테이블에 있는 그 프로세스 항목을 제외한 모든 것이 사라집니다. 그 항목은 부모 프로세스가 자식 프로세스의 반환 상태를 회수하기 전까지 지워지지 않고 남습니다. 반환 상태는 프로세스가 일을 정상적으로 마쳤는지를 나타냅니다. 'echo $?' 명령어를 통해 커맨드 라인로 실행한 마지막 명령어의 상태(기본적으로 반환 상태가 0인 경우만 정상 종료로 취급)를 확인할 수 있습니다. 프로세스가 zombie 상태로 진입하면 다른 상태로 진입하기 위해 필요한 것들이 모두 사라지기 때문에 더 이상 다른 상태로 진입할 수 없게 됩니다.

  만약 자식 프로세스가 죽기 전에 부모 프로세스가 죽으면 자식 프로세스는 고아가 되어 init 프로세스에게 입양되는데 이는 init이 그 프로세스의 새 부모가 된다는 것을 의미합니다.

Load Average란 무엇인가?
  시스템 자원 사용률을 측정하는 프로그램들에서 load average라는 것을 쉽게 볼 수 있는데 이는 실행을 기다리는 프로세스 큐의 현재 길이의 평균값을 뜻합니다. 리눅스의 경우 이 수치는 실제 실행 중인 큐(actual run queue), 실행 가능한 큐(runnable queue), 깨울 수 없는(uninterruptable) sleep 상태에 빠진 프로세스 개수의 조합으로 결정됩니다. CPU 사용률과 load average 값이 함께 높을 때도 있지만 일반적으로 load average 값이 높다는 것은 프로세스들이 입출력 대기 때문에 일을 끝내지 못하고 기다리고 있다는 것을 의미합니다. 그러므로 리눅스의 경우 CPU 사용률과는 무관하게 load average가 높다면 프로세스가 CPU를 사용하기 위해 대기하는 시간이 길어지게 되어 모든 것이 느려지게 됩니다.
2013/12/10 17:50 2013/12/10 17:50