A. Influential Operating Systems

영향력 있는 운영 체제들을 알아보자.

A.1. Feature Migration

초기 운영 체제를 연구하는 이유 하나는 최초에는 대형 시스템에서만 가동되었던 특성이 마지막에는 초소형 시스템에서도 가동되기 때문이다. 이 예 중 하나는 컴퓨팅 유틸리티로 개발된 MULTICS가 있다.

A.2. Early Systems

초기의 컴퓨터 시스템을 알아보자. 1940년대에 내장 프로그램 컴퓨터의 개념이 나왔다. 이후 범용 컴퓨터가 나왔다. 초기 컴퓨터는 콘솔로 가동되는 물리적으로 초대형인 기기들이었다.

A.2.1. Dedicated Computer Systems

시간이 지나면서, 추가 소프트웨어와 하드웨어가 개발되었다. 입출력을 수행하는 루틴들은 특별히 중요하였다. 이후 FORTRAN, COBOL, 다른 언어 등에 대한 컴파일러가 나타나 프로그래밍을 더 쉽게 했지만 컴퓨터의 동작은 더 복잡해졌다. 작업 수행 시 상당한 셋업 시간이 걸렸다. 컴퓨터의 가격도 비쌌으므로 활용량을 최대화해야 했다.

A.2.2. Shared Computer Systems

해법은 두 가지였는데 첫 번째는 전문적인 컴퓨터 오퍼레이터가 고용된 것이고 두 번째는 비슷한 필요성을 가진 작업들이 묶여서 수행되어 셋업 시간을 줄였다. 그러나 여전히 유휴 시간은 남아 있었다. 이를 줄이기 위해 사람들은 상주 모니터에 의해 관리되는 자동 작업 배열을 개발했다. 컴퓨터가 켜졌을 때 상주 모니터가 작동해 제어를 프로그램으로 옮겼다. 어떤 프로그램이 실행될지는 제어 카드로 결정되었다. 각 작업의 경계에도 제어 카드가 필요했다. 제어 카드의 문제는 프로그램 카드와 데이터를 구별하는 것이었는데, 이는 특수문자로 이루어졌다. 그래서 상주 모니터는 제어 카드 인터프리터, 로더, 디바이스 드라이버로 이루어졌다. 이 배치 시스템은 잘 동작했다. 이로의 전환은 성능을 개선하기 위해 이루어졌다. 이 조정 이후에도 CPU는 자주 유휴 상태가 되었는데, 문제는 물리적 입출격 기기의 속도에 있었다.

A.2.3. Overlapped I/O

입출력 문제의 한 해법은 느린 카드 리더와 라인 프린터를 마그네틱 테이프 유닛으로 대체한 것이다. 이로서 카드 리더와 라인 프린터는 오프라인으로 동작하게 되었는데 이를 통해 메인 컴퓨터의 속도가 이들에 의존하지 않게 되었다. 또한, 한 CPU가 복수의 리더와 프린터를 사용함으로써 속도는 더 개선되었다. 하지만 테이프는 순차적 접근 기기였기 때문에 무작위 접근 기기인 디스크에 의해 대체되었다. 디스크 시스템에서 프로세스는 스풀링될 수 있었는데 이는 디스크를 읽기/쓰기 시 큰 버퍼로 사용했다. 스풀링은 원격 지역에서 데이터 처리에 쓰이기도 했다. 이는 한 작업의 입출력을 다른 작업의 연산과 겹치게 하였다. 스풀링은 시스템의 성능에 직접적인 이득을 주었다.

A.3. Atlas

아틀라스 운영 체제는 1960년대에 개발되었다. 이는 스풀링을 도입한 배치 운영 체제이다. 당시에는 코어 메모리가 비쌌기 때문에 아틀라스가 드럼을 메인 메모리로 삼고 코어 메모리를 캐시로 쓴 것은 매우 중요했다. 아틀라스는 48비트 단어를 썼다. 페이지 폴트가 일어나면 페이지 대체 알고리즘이 실행되었다.

A.4. XDS-940

XDS-940 운영 체제는 1960년대 초반에 개발되었다. 이는 XDS-930의 수정 형태로부터 만들어졌다. 사용자 모드 명령어 집합에 시스템 호출 명령어가 추가되었다. XDS-940은 시스템 호출을 제공해 프로세스가 부분 프로세스를 생성, 시작, 중지, 소멸시킬 수 있게 하였다.

A.5. THE

THE 운영 체제는 1960년대 중반에 개발되었다. XDS-940 프로세스와는 다르게, THE 시스템의 프로세스는 정적이었다. 우선도 기반 CPU 스케쥴링 알고리즘이 사용되었다. 하드웨어 지원의 부족으로 인해 메모리 관리는 제한되었다. 데드락을 피하기 위해 은행가 알고리즘이 사용되었다. Venus 시스템은 밀접한 관련이 있다.

A.6. RC 4000

RC 4000 시스템은 1960년대 후반에 개발되었다. 커널은 메시지 시스템을 통해 통신과 동기화 메커니즘을 제공하였다. 메시지 큐는 각 프로세스마다 부여되었다. 프로세스는 선입선출 순서로 메시지 큐를 수행했으며 다른 프로세스가 메시지를 수행하는 동안에는 스스로를 가로막았다. 입출력 디바이스도 프로세스로 다뤄졌다.

A.7. CTSS

호환 가능한 시간 공유 시스템(CTSS)는 실험적 시간 공유 시스템이었다. IBM 7090은 36비트 워드로 이루어진 32KB 메모리를 가졌다. CTSS는 매우 성공적이었으며 1972년까지 사용되었다.

A.8. MULTICS

MULTICS 운영 체제는 1965~1970년에 개발되었다. 이는 MIT, GE, Bell 연구소에서 개발되었다. MULTICS에서 가상 주소는 18비트 세그먼트 번호와 16비트 워드 오프셋으로 이루어졌다. 세그먼트 가상 주소는 파일 시스템으로 병합되었고, 각 세그먼트는 파일이었다. CTSS처럼, MULTICS는 CPU 스케쥴링에 대해 다층 피드백 큐를 썼다.

A.9. IBM OS/360

운영 체제 개발의 가장 긴 역사는 IBM 컴퓨터의 것이다. IBM/360은 1960년대 중반에 등장하였는데, 많은 서로 다른 언어와 시스템 소프트웨어를 가진 서로 다른 컴퓨터를 통합 관리하기 위해 설계되었다. 하지만 어느 것도 특출나게 이루지는 못했다. 그 구조로 인해 메모리 관리 루틴은 제대로 되지 못했다. 시스템은 수천 명의 프로그래머에 의해서 수백만 줄의 어셈블리 언어로 쓰였다. IBM/370 아키텍쳐의 변화와 함께 OS/360에는 가상 메모리가 추가되었다. 여전히 MVS는 기본적으로 배치 운영 체제였다. OS/360에는 시간 공유 옵션도 추가되었다. IBM은 자체 시간 공유 시스템인 TSS/360을 시도했으나 실패하였다. 이는 이해하기에 너무 컸고 너무 복잡했기 때문이다.

A.10. TOPS-20

DEC는 여러 영향력 있는 컴퓨터 시스템을 남겼는데 그 중 가장 유명한 것은 VMS였다. TOPS-20은 1970년대에 연구 프로젝트로 시작되었다. 이는 사용자에게 필요가 생겼을 때 도움을 주는 고급 커맨드 라인 인터프리터를 가졌다.

A.11. CP/M and MS/DOS

1970년대의 표준 운영 체제는 CP/M이었다. IBM은 Intel 8086에서 16비트 CPU를 위한 운영 체제인 MS-DOS를 개발하였다.

A.12. Macintosh Operating System and Windows

애플 매킨토시는 가정용으로 설계된 GUI를 가진 최초의 컴퓨터였다. 원본 Mac OS는 애플 컴퓨터에서만 동작하였으며 여러 컴퓨터에서 동작할 수 있었던 Microsoft Windows에 서서히 대체되었다. Mac OS, 윈도우, 리눅스 등은 초저가형 노트북 PC(OLPC) 등에서도 경쟁을 이어가고 있다.

A.13. Mach

Mach 운영 체제는 Accent 운영 체제로 거슬러 올라간다. Mach의 개발은 1980년대 중반에 시작되었다. 이는 BSD UNIX 시스템의 혁신으로 이어졌다. 버전 2 배포를 통해, Mach는 커널에 BSD 코드 중 다수를 포함해 BSD 시스템과의 호환성을 확보했다. 오픈 소프트웨어 재단 (OSF)가 1989년에 Mach 2.5를 OSF/1의 기반으로 사용하면서 산업 첨단의 주목을 끌었다. UNIX와는 달리 Mach는 멀티프로세싱을 내내 지원했다. 오늘날 남아 있는 순수 Mach 구현은 GNU HURD 뿐이다.

A.14 Capability-based Systems-Hydra and CAP

2개의 자격 기준 보호 시스템을 알아보자.

A.14.1. Hydra

Hydra는 유의미한 유연성을 제공하는 자격 기반 보호 시스템이다. 오브젝트의 정의가 Hydra에 인식되면 그 타입에 대한 동작명들은 보조 권리가 된다. Hydra는 권리 증폭도 구현하였다. 이는 구현 프로시져가 추상 자료형의 표현 변수에 접근할 수 있도록 하였다. 권리 증폭은 Hydra 운영 체제의 추상 자료형 선언으로 명시적으로 표현될 수 있었다. 권리 증폭으로 인해 사용자 보호가 깨질 때도 있었는데 Hydra는 증폭을 제한해서 해결했다. Hydra의 프로시져 호출 메커니즘은 상호 신뢰 불가능한 부분시스템의 문제에 대한 해결책이 되었다. Hydra 부분 시스템은 보호 커널의 맨 위에 세워져 자체 컴포넌트에 대한 보호를 요구했다. 프로그래머는 적절한 참고 매뉴얼의 특성을 익히고 나면 보호 시스템을 직접 사용할 수 있었다.

A.14.2. Cambridge CAP System

CAP은 데이터 자격소프트웨어 자격 두 종류를 제공했다. 소프트웨어 자격의 표현은 완전히 부분시스템이 갖고 있는 보호 프로시져를 통해 이루어졌다. CAP 시스템의 설계자들은 소프트웨어 자격의 사용을 통해 추상적 자원의 요구 조건에 맞는 보호 정책을 진술하고 구현하는 것을 가능케 했다.

A.15. Other Systems

다른 운영체제도 있으며 여러 흥미로운 특성을 가지고 있다. 운영 체제는 점점 더 발전하고 있으며 더 개선된 운영 체제들이 이전의 것들을 대체해 나가고 있다.

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Google photo

Google의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

%s에 연결하는 중