[카테고리:] 운영체제 이야기

터미널에서 특정 폴더에 디스크 이미지 마운트하기

이전에 쓴 Case-sensitive partition 생성에 그냥 이어서 진행합니다.

디스크 이미지를 마운트 하는 것도 hdiutil을 이용합니다. 작업 순서는 다음과 같습니다.

  1. 마운트할 폴더를 생성한다. 본인이 쓰기 편한 폴더를 만들어서 거기에 마운트 시키면 된다.
  2. 해당 폴더에 아래 명령어를 입력하여 마운트를 시킨다.

hdiutil attach ~/ext_disk.dmg -mountpoint ~/ext_disk

스크린샷 2014-02-07 오후 9.40.42

위에 처럼 디스크 정보를 보여주면서 출력 되면 마운트가 된 상황입니다.

근데 이게 글 하나를 쓸 정도의 내용인가요?

이거 자기가 뭔 작업했는지 모르면 무지 헷갈립니다. ㅇㅅㅇ;;

제가 제 홈폴더에 직접 작업을 했습니다. 이걸 파인더로 열어서 보면 어떤 상황일까요? 그냥 ext_disk란 폴더랑 ext_disk.dmg 파일 있겠지라고 생각하시겠죠?

 

GUI로만 보면 모릅니다. ㅇㅅㅇ 저기 밑에 보면 untitled 라고 되어 있는 장비에 있는 것이 마운트 된 것이라는 건 누구나 알겠지만, 저 홈폴더 밑에 목록에 똑같이 untitled라고 나와 있는 것이 ext_disk 폴더라는 것은 모를 수 있습니다. 이걸 터미널로 확인해 보죠.

ext_disk 라고 제대로 폴더 표기도 되어있죠? 저기로 이동하면 그대로 파일 쓰고 할 수도 있도록 되어 있습니다. 리눅스에 익숙한 분들이라면 이런 사용방법 좋아하실지도요. ㅇㅂㅇ;

저도 첨에 뭐가 뭔지 몰랐던 바보같은 짓을 했었기에 한번 알려드리려고 적어봤습니다.

p.s. 규링은 첨에 삽질 많이 합니다….
p.s.2. 이건 일본의 어떤 이상한 용자 블로그에서 찾은 글인데.. 저기에 공개 키 이용해서 맘대로 마운트 못하게 하는 디스크 만들고 거기다 ㅇㄷ 넣는 인간들도 있다고 합니다. (왜그러냐..)

Case-sensitive partition 생성

이전 글에서 대소문자 구분 가능한 파티션과 그렇지 않은 파티션이 있다고 대충 알려만 준 상태인데… 그럼 대소문자 구분 가능한 파티션을 일일이 디스크 관리에서 만들고 해야 할까요?

아뇨. 터미널 열고 명령어 한번만 치면 dmg 이미지 파일(디스크 이미지 파일)을 쉽게 만들 수 있습니다. (생성 시간은 좀 걸립니다)

hdiutil create -fs ‘Case-sensitive Journaled HFS+’ -size 40g ~/ext_disk.dmg

맥 OS X에서의 이미지 생성 툴인 hdiutil 명령을 이용하여 생성할 수 있습니다. 사용 방법은 이 링크를 클릭하시면 애플 개발자 센터 문서를 보실 수 있습니다. 내용이 많기 때문에 우선 명령어로 쓴 부분만 간단하게 설명을 드리기로 하죠.

  • -fs [파일시스템]: 파일 시스템을 적습니다. 오타 하나라도 나면 안되기 때문에 반드시 문서를 보고 쓰셔야 합니다.
  • -size [용량]: 디스크 이미지 파일의 용량을 지정합니다. 고정 용량이기 때문에 저처럼 바로 40g로 잡고 하면 디스크 용량이 40G 줄어들어 있을 겁니다. ㅇㅅㅇ;;
  • [파일 이름]: 생성할 파일 디렉토리와 파일 이름을 지정해 줍니다.

스크립트를 실행한 후에 파일이 생겼는지 확인했습니다.

 

용량 제대로 먹고 있습니다. ㅇㅅㅇ;;

그럼 이걸 마운트 해서 써야겠죠? GUI 에서 마운트 하는 것이야 더블클릭 하면 됩니다. 그리고 Volume 폴더에서 찾아서 들어가면 됩니다. 그러나, 리눅스와 유닉스 같이 원하는 폴더에 마운트하여 쓸 수도 있습니다. 그 방법을 알려드리겠습니다.

case-preserving but case-insensitive

맥 OS의 파티션에 대해서 알아볼 때, 다음과 같은 경우를 볼 수 있습니다. (디스크 관리에서 파티션 설정하고 포맷할 때 보실 수 있습니다.

 

Mac OS X 확장에 보시면 한글로는 대소문자 구분이라고 되어 있죠. 근데 아마 여러분이 처음 사신 맥의 파티션에는 대소문자 구분에 대한 것이 안되어 있는 그냥 일반 저널링만 된 파티션이 보일 것입니다.

근데 이게 제가 쓰면서 알게 된 글의 대상이 되었습니다. 바로 다른 소스에 크로스 컴파일을 할 때(특히 리눅스에서만 동작하는 소스들)을 쓸 때 여러모로 문제가 되더군요. Git같은 버전관리 시스템의 경우에도 대소문자 구분되는 파티션 시스템에서 처리되는 것과 아닌 것에 대해서는 동작이 전혀 다르게 돌아가기도 합니다. (잘 되긴 하죠. 근데 몇몇 분들처럼 warning을 보기 싫다면 파티션 같은 부분도 고려해야 합니다만..)

이번에 제가 리눅스 커널 소스를 맥에서 빌드해 보면서 case-sensitive 파일시스템을 사용한 디스크 파티션이 필요해서 여러모로 알아보다가 이게 차이가 있는 녀석이란 걸 알게 되었습니다.

다음 글에는 case-sensitive한 파티션을 만들어서 쓰는 방법을 소개해 드리겠습니다.

Single UNIX Specification

단일 유닉스 규격(Single UNIX Specification)은 컴퓨터 운영체제가 유닉스란 이름을 사용하기 위해 지켜야 하는 규약을 말한다.

이 규격은 1980년대 중반, 여러 유닉스 계열의 인터페이스를 표준화하기 위해서 시작한 프로젝트에서부터 시작하게 되었다. 업체마다 각기 다른 운영체제 사이의 소프트웨어 이식에 들어가는 비용을 되도록이면 줄여달라는 운영 기업들의 요청으로 인해 시작되었다. 이때, 표준화 운영체제로 선택된 운영체제는 유닉스인데 유닉스가 특정 회사에 의해서 만들어진 운영체제가 아닌 데다가 특정 회사 제품에 의한 종속성이 없었기 때문에 유닉스를 사용하게 되었다. 이 프로젝트로 만들어진 것이 바로 POSIX이다.

그러나 1990년대, 이시기에는 유닉스 전쟁이란 말로 전부 해설이 가능한 시기이다. 몇 군데의 회사들이 COSE(Common Open Source Environment) 협정을 결성하여, Common API Specification 또는 Spec 1170이라 불리는 사양을 내놓았다. 이 사양은 POSIX와는 달리 무료로 입수할 수 있었기에 IEEE에 접근하여 인증받는 비용을 부담해야 하는 POSIX보다 널리 일반화되었다. 1998년에 Austin Group이라 불리는 공동의 워킹 그룹이 이 사양들의 통합을 시작하여, 그 결과로 Single UNIX Specification version 3(단일 유닉스 규격 제3판)이 탄생하게 된다.

단일 유닉스 규격에서 규정하는 운영체제와 사용자 및 소프트웨어 사이의 인터페이스는 다음의 4 가지로 분류된다.

  • Base Definitions : 표준 규격을 기술하는 데 사용되고 있는 정의와 규약 등의 목록과, 이에 따르는 운영체제가 반드시 제공해야 할 C 언어의 헤더 파일 목록들.
  • Shell and Utilities : 유틸리티(약 160개의 명령들)의 목록 및 셸(sh)의 내역.
  • System Interfaces : 제공되어야 하는 시스템 호출 및 C 라이브러리의 목록들.
  • Rationale : 위의 표준에 대한 해설들.

이 표준에 의한 사용자 명령 줄 인터페이스와 스크립트 인터페이스는 초기 콘 셸에 바탕을 둔 본 셸의 확장판인 POSIX 셸이다. 이 밖에 사용자 레벨의 프로그램 또는 서비스, 유틸리티로는 awk, echo, ed 등 수백여개의 목록이 포함되어 있다. 프로그램 레벨에서 필요로 하는 서비스로는 입출력(파일, 터미널, 네트워크) 등이 있다. 이 표준을 테스트하는 프로그램 모음인 PCTS(Posix Certification Test Suite)가 있다. PCTS는 NIST에서 오픈 소스로 공개되어 있다.

이 사양이 알려주는 것중에 제일 주의할 점은 사양을 만족하기 위해 AT&T의 유닉스 소스 코드를 사용하지 않아도 된다는 점을 주의해야 한다. (실제의 예로, IBM의 z/OS (OS/390)은 소스코드는 완전히 독자적으로 만들어졌으나, ‘UNIX’란 이름을 사용하도록 허용받고 있다.)

단일 유닉스 규격을 따르고 있는 유닉스들은 다음과 같다.

  • AIX
  • HP-UX
  • Mac OS X: 10.5 레오파드부터 인증에 통과했다.
  • Reliant UNIX

  • SCO
  • Solaris
  • Tru64 Unix
  • z/OS
  • NCR UNIX SVR4
  • NEC UX/4800
  • SGI IRIX 6.5

유닉스 계열로 분류되면서 단일 유닉스 규격을 만족하지 않는 운영체제들

  • BSD 계열: C99 and POSIX Conformance Project에 의해 제작된 BSD 계열은 단일 유닉스 규격을 만족하지 않는다. FreeBSD, OpenBSD도 마찬가지 이유. ㅇㅂㅇ
  • 리눅스: 유닉스 운영체제에서 파생되어 나온 것이지만 전체적으로 규격이 많이 다르다.

PC-UNIX

음… 솔직히 말하면 이게 상당히 애매한 용어이다. 왜 애매한 용어인지를 알려주겠다는 식의 글이라 보시면 될 거 같다.

PC-UNIX는 PC에서도 동작을 하는 유닉스를 말한다. 근데 이게 용어로 써있는 책을 잘 뒤져봐라.. 미국과 유럽 계열에서는 거의 없을 것이다. 주로 아시아 계열의 책이나 용어집에서는 반드시 나온다. (위키백과에서도 영어로 써있지도 않다. ㅡㅅㅡ;;)

이 용어를 주로 쓰는 곳은 바로 일본이다. ㅡㅅㅡ 주로 운영체제에 대한 서적을 뒤져보면 PC에서 동작하도록 나온 유닉스를 말하며, 원래 명칭으로는 Unix-like system의 일부분중 PC에서 돌아가는 녀석들을 모아다가 죄다 PC-UNIX라고 써놨다.

원서보면 거의 헷갈리는데 이 용어가 나중에 산업기사/기사 보는 분들은 꼭 한번씩은 접한다. 그러다 보면 이 용어갖고 여러모로 말이 무지 많이 돌기도 한다. (근데 현업에서만 개발하는 인간들은 그런 거 필요없다. ㅡㅅㅡ)

이 용어에 대한 일본측 원서에서는 이 운영체제들에 대해 이와 비슷하게 정의하고 있다. [고가의 대형 컴퓨터를 동작시키기 위한 Unix를 PC에서 이용할 수 있도록 아키텍쳐 지원과 메모리 관리 기능의 수정 등을 통하여 PC에서 동작이 가능하도록 만든다. 단, 유닉스에서 사용할 수 있는 기능들은 거의 그대로 이용할 수 있도록 지원하는 것을 전제로 한다.] 라고들 써 있다. 아니면 이 문장 순서의 변경이 있긴 하겠지만 기본적으로는 PC에서 동작 가능하도록 설정은 다 맞춰주면서 기능은 그대로 가져간단 것이다. 뭐, 유닉스 시스템이 그만큼 성능적으로는 인증되어 있는 시스템이니 그럴 수 밖에 없겠지만..

일단 여기에 속하는 듯하게 적어놓은(?) 유닉스 계열의 시스템들은 다음과 같다.

  • PANIX
  • XENIX
  • Linux
  • FreeBSD
  • NetBSD
  • OpenBSD
  • Solaris/OpenSolaris

…좀이라도 유닉스 시스템을 아는 사람들은 바로 보고 눈치챘을 것이다. 여기에 있을 필요가 없는 녀석이 하나 눈에 띈다는 것을…ㅡㅅㅡ;; 그리고 대놓고 타분류화된 녀석이 또 하나 있다…ㅡㅂㅡ;;

애당초 리눅스의 탄생이 PC에서 돌리는 유닉스였고, 솔라리스는 x86 플랫폼 지원을 하다 보니 어쩌다 PC도 지원한다. 게다가 10부터 오픈소스화 되는 바람에 PC에서 돌아가야 하는 상황이었고, 오픈솔라리스는 원래부터 대상이 PC다. ㅡㅅㅡ

뭐, 이것저것 골때리는 용어이긴 한데.. 그냥 PC 구동용 유닉스라고만 대충 생각하고 넘기면 될 듯 하다..

POSIX(Portable Operatiing System Interface)…?

POSIX(Portable Operatiing System Interface)는 서로 다른 유닉스 운영체제의 공통 API를 정리하여 이식성이 높은 유닉스 운영체제 프로그램 개발을 위한 목적으로 정의된 인터페이스 규격입니다. 규격의 정의는 IEEE에 정의가 되어 있고, 최신 규격으로는 2.0 버전까지 정의되어 있습니다.

유닉스의 장점인 높은 이식성은 바로 이 규격을 통하여 이용되는 장점이죠… 커널 수준의 시스템 콜뿐만 아니라 사용자 레벨 프로그램, 프로세스 환경, 파일과 디렉토리 관련, 시스템 데이터베이스, 압축 포맷 등등의 다양한 분야에서 이용되는 표준 규격 인터페이스이기 때문에 여러 유닉스, 리눅스에서도 거의 동일하게 프로그램 소스를 컴파일해서 이용할 수 있는 장점을 가지게 되는 겁니다.

실제로 사용하는 데 있어서 차이점이 있다면 각 운영체제마다 가지는 환경적인 특징들만 차이가 날 것이지 쓰는데는 별 지장이 없다는 것을 알게 될 겁니다. 유닉스, 리눅스 프로그램들의 경우에는 프로그램 바이너리 파일만 받아서 그대로 make 돌려도 거의 바로 이용할 수 있는 게 바로 이 POSIX 규격에 맞춘 프로그램 바이너리이기 때문이죠. 소스 코드만 받아서 바로 컴파일 해서 쓰는 프로그램들도 표준 C 컴파일러조차 POSIX 규격에 맞춰서 시스템마다 동일하게 적용되어 있기 때문입니다. 간혹 페도라라던가 AIX와 같이 독자 환경이 있는 경우에는 좀 손을 봐서 처리해야 겠지만 규격에 준수가 되어 있는 대부분의 유닉스, 리눅스에서는 별 문제가 없습니다….ㅇㅅㅇ;;

윈도우 NT 계열에서도 POSIX 서브시스템을 탑재하고 있어서, POSIX 응용 프로그램을 서브시스템에서 실행할 수 있었습니다. 이게 윈도우 2000까지는 POSIX 서브시스템을 탑제하고 있었으나, XP에서 폐지되었습니다. 이후에 2003 서버에서부터 POSIX 2.0을 준수하는 서브시스템을 통하여 POSIX를 지원하는 형식으로 갖추고 있게 되었습니다. 윈도우에 보면 프로그램 추가/제거에 보면 유닉스 서브시스템이라고 되어 있는 것이 이 POSIX 지원 기능이죠. ㅇㅅㅇ;;

헷갈리면 안되는 게 윈도우 XP에 프로그램 추가 -> 윈도우 추가 제거에 보면 유닉스 시스템에서 프린터 공유하는 기능이 있습니다. 이걸 착각해서 예기하는 분이 있긴 한데.. 이거 아닙니다…ㅡㅅㅡ;;; 옛날부터 있던 프린터 공유 기능입니다.

MINIX…?

유닉스 운영체제를 공부할 때 해외에서 주로 이용하는 운영체제이다. 네델란드의 암스테르담 자유학교에 재직하던 교수 앤드루 타넨바움(Andrew Tanenbaum)에 의해서 교육용으로 만들어진 유닉스이다. 어원명은 mini-UNIX라고 한다.

미닉스의 커널이 리눅스 커널의 영감을 주게 되었다는 것이 리눅스 탄생설이다. (근데 진짜다.)

미닉스의 최신버전이 MINIX 3의 커널은 다른 커널과는 달리 마이크로 커널을 채용하였다. 커널 제작 라인도 그렇게 많지도 않고, 소스코드도 그렇게 많이 들어있지 않은 편이다. 따라서, 쉽게 재작해서 쓰면서 동시에 OS 공부도 할 수 있기 때문에 미국, 유럽 지역에서는 자주 사용되는 녀석이다. 요즘은 리눅스로도 할 수 있지만…

일단 좀만 더 깊이 공부해 보신 분들은 알겠지만 유닉스랑 리눅스는 커널 자체가 완전 다릅니다. 그렇기 때문에 유닉스를 기반으로 본격적인 OS 커널을 다루고자 하실때는 이걸 주로 이용하죠. 근데 오픈솔라리스 등의 유닉스 계열의 오픈소스들도 많다보니 굳이 이걸 쓸 일이 없어졌지만요..^^;;

본인이 마이크로커널에 관심이 많다면 한번 제대로 봐보세요. 공부 많이 됩니다.

Unix…?

이걸 모르고는 뭔 넘의 컴퓨터 역사와 운영체제를 논하리오!!!! ㅇㅁㅇ/

AT&T 벨 연구소에서 개발한 운영체제이다. 워크스테이션, 서버, 메인프레임 등에서 쓰이기 시작하였으며 데스크탑용, 임베디드용으로도 널리 쓰이고 있다. (지금은 리눅스에게 밀리는 거 같아 보이지만 그래도 여전히 유닉스 쓰는 곳 많다.)

컴퓨터 역사상으로도 엄청나게 중요한 운영체제이다. 지금 현재 프로그래밍 언어공부의 시작이자 업계 표준인 C언어도 원래는 유닉스를 프로그래밍하기 위해서 만들어진 것이다. ㅇㅁㅇ?! 이때 당시의 서버나 메인프레임 운영에 쓰이던 프로그래밍 언어는 전부 어셈블리어로 개발되어 기계어랑 1:1 대응되어 다른 하드웨어 이식 등에 여러 문제를 가지고 있었으나, 유닉스가 C언어라는고급언어로 만들어지면서 하드웨어 이식에 따른 제약이 사라지게 되었다. 여기에 추가로 당시 최신 기술이었던 멀티테스킹 기술을 가지고 있었기 때문에 인기가 많았다.

몇십년동안 자라온 CLI 기술의 축적이 강하기 때문에 윈도우 서버보다 더 인기가 강하다. 특히 초 대용량 서버들은 유닉스와 윈도우 서버로 양분되어 있다고 보면 된다. (리눅스는 초대형 시스템 구축에는 좀 어려운 점이 있다.) iOS, Android도 유닉스를 기반으로 만들어졌다고 보면 되겠다. 뭐, 정확하게 말하면 안드로이드는 리눅스에 가깝겠지만.. 위로 올라가면 다 유닉스로 올라가겠지..;;

추가로 인터넷 역사와도 함께 한다. OS가 인터넷으로 접근하기 위해 이용하는 소캣도 BSD 유닉스에서 만들어져서 사용되는 것이다. ㅇㅁㅇ?!?!

이렇듯 상당히 다양한 곳에서 역사와 함께한 시스템이므로 컴퓨터를 공부하는 사람들은 알아두면 좋은 게 많은 운영체제이다.

Year 2038 Problem – Another Unix Millennium bug

한참 옛날 일이 되어버렸지만 Y2K 라는 문제가 있었다. 컴퓨터가 날짜 계산시, 특히 1999년 12월 31일에서 2000년 1월 1일로 넘어갈 때 연도를 1900년도로 인식하여 날짜 계산에 엄청난 오류가 발생할 것이라는 인식하지 못할 것이라는 일종의 컴퓨터 설계 버그였다. 컴퓨터의 메모리가 용량은 적고 값은 무지 비쌌을 시절에 천공카드 사용시 1969년을 그냥 69년으로 표기하면 카드에 들어가는 데이터의 용량을 그나마 줄일 수 있었던 시절의 설계 오류였으나 몇몇 문제가 있는 것을 제외하고는 별 문제가 없이 끝났던 사건이었다. (이를 밀레니엄 버그라고 한다.)

근데 이젠 또 다른 시스템의 시계 문제가 불거졌다. 바로 2038년 문제라고도 하는 유닉스의 밀레니엄 버그이다. 근데 이거에 대해서는 현재 업계 종사자 대부분의 사람들이 별 걱정하지 않고 있다. 그렇다면 이게 무슨 문제이고, 왜 그냥 막 넘어가는 걸까?

POSIX 규격에 따른 시간 표기법에 의하면, 시간을 1970년 1월 1일 자정 UTC 시간 이후부터 경과된 초 시간을 이용하여 시간을 표기한다. 이 표기법은 대부분의 유닉스, 리눅스 계열의 OS에서는 거의 공통적으로 나타나는 표기 형식이고, POSIX를 지원하는 기타 운영체제들 또한 마찬가지로 일어나는 형식이다. POSIX 규격에 맞춰서 개발되었다면 C로 개발되었을 것이고, C의 데이터 표기 체계에 맞춰진 대부분은 32비트 시스템에서 초 시간을 저장하는 데 이용되는 time_t 자료 형식을 그대로 이용한다고 보면 된다.

time_t 자료 형식은 부호 있는 32비트 정수형이다. POSIX 표준에 따르면 이 형식을 이용하여 나타낼 수 있는 최후의 시각은 1970년 1월 1일 자정에서부터 정확히 2147483647초가 지난 2038년 1월 19일 화요일 03시 14분 7초 (UTC)이다. 이 시각을 지나면 시각 표기 자릿수 범위를 초과하여 내부적으로 음수로 표현되고 프로그램의 이상 작동을 유발하게 된다. 프로그램 구현 방법에 따라서 년도 값이 2038년이 아닌 1970년 또는 1901년으로 표기되기 때문에 기존에 있던 자료들의 생성 시간과의 차이가 생기게 된다. 이는 치명적인 오류를 낳게 된다. 상대시간 표기 오류가 발생하거나 바이너리 수준의 호환성 오류가 발생하여 파일이나 프로그램을 정상적으로 실행시킬 수 없게 된다.

이 문제의 해결책은 의외로 간단하다. 현재 나오는 CPU와 OS들이 이 문제를 다 해결해 주고 있다. 바로 64비트 아키텍쳐를 이용하면 된다. 표현되는 확장 범위가 32비트에서 64비트로 넘어가면 그만큼의 시간은 무지 길어지게 된다. 64비트 정수 체계로 넘기면 대략 계산 가능한 시간은 1970년 1월 1일 자정을 기준으로 9223372036854775807초를 경과한 2922억 7702만 6596년 12월 4일 일요일 15시 30분 8초 (UTC)까지 진행할 수 있게 된다. 근데 이 글을 보고 있는 여러분이 이 시간까지 살아서 오류가 날지 안날지를 지켜볼 수 있을 거라 생각하는가…? 최소한 태양의 수명이 앞으로 약 123억년이라고 하였고, 현대 과학은 아직은 시간 도약을 할 수 있는 기술이 없다. 그냥 잘~ 해결된다고 보면 된다. ㅡㅅㅡ;;;

현재 대부분의 PC의 경우에는 64비트 운영체제와 프로세서로 전환되고 있는 실정이기 때문에 문제 없이 진행이 될 수 있으나, 임베디드 장비들의 경우에는 아직도 심각한 문제일 수 있다. 임베디드형 연산은 아직까지도 최대 32비트 연산체계를 벗어나지 못하였기 때문이다. 거의 수많은 임베디드 시스템이 2038년에 모두 교체가 될지부터 엄청난 미지수이지만 눈앞에 당장 바로바로 사용되는 것들의 경우에는 쉽게 교체가 이루어질 수 있을 거란 전망이다. 단, 스마트폰 빼고는…ㅡㅅㅡ

(스마트폰 제조사들은 오버클럭 매니아들처럼 클럭 수 올리는 거에 혈안두지 말고 64비트 지원이나 먼저 신경 좀 쓰지…ㅡㅅㅡ)