shopkeeper/korean_wiki_content_only_120125 huggingface dataset:
이 웹사이트는 출시 예정인 모델들의 미리 보기에도 사용되었다. 특히 중국 회사 딥시크는 R1 모델이 서구 언론의 주목을 받기 몇 달 전에 LMArena에서 프로토타입 모델을 테스트했다. 다른 주목할 만한 사전 출시 모델로는 코드명 "서밋"으로 알려진 오픈AI의 GPT-5와 코드명 "Nano Banana"로 알려진 이미지 생성 및 편집 모델인 구글 딥마인드의 제미나이 2.5 플래시 이미지(Gemini 2.5 Flash Image)가 있다.
LMArena의 대형 언어 모델 평가 방법론은 학술 분석에서 검토되었으며, 특정 한계를 식별하고 개선할 영역을 제안했다. 이 플랫폼은 AI 연구 생태계의 활발한 기여자이며, 정책 업데이트를 통해 진행 중인 연구와 협력하여 방법론적 업데이트를 구현했다.
마누스(Manus)는 아래 뜻을 함의한다.
마누스(Manus, 라틴어로 손을 뜻함)는 싱가포르에 본사를 둔 모니카를 만든 동일한 스타트업이 개발한 자율적인 인공지능 에이전트이다. 이 에이전트는 직접적이거나 지속적인 인간의 지도 없이 복잡한 실제 작업을 독립적으로 수행하도록 설계되었다. 일부 언론에서는 이 에이전트가 독립적인 사고, 동적 계획, 의사 결정이 가능한 세계 최초의 자율 에이전트 중 하나로 평가하고 있다.
샤오 홍은 Manus.im의 주요 인물이다. 그의 경력 초기에 그는 "이반 어시스턴트"와 "웨이반 어시스턴트"와 같은 생산성 도구를 만든 나이팅게일 테크놀로지를 설립했는데, 이들은 기업 사용자들 사이에서 널리 활용되는 AI 기반 플랫폼이다. 그의 "키트배싱" 접근 방식으로 알려진 샤오는 위챗과 같은 기존 플랫폼에 AI 기능을 통합하여 향상시키는 목표에 집중했다.
마누스는 대형 언어 모델 (LLM)을 기반으로 독립적으로 작동할 수 있는 인공지능 에이전트를 만들기 위해 설립되었다. 마누스는 2025년 3월 6일에 공식적으로 출시되었다. 벤처비트(VentureBeat)는 마누스가 코드 작성 및 배포를 포함한 복잡한 작업을 자율적으로 처리할 수 있다는 점에서 주요한 진전이라고 설명했다. 마누스는 직접적인 인간 개입 없이 완전히 작동하고 코드 작성 및 배포를 포함한 복잡한 작업을 자율적으로 완료할 수 있는 능력으로 인해 인공지능 개발의 전환점으로 묘사되었다.
FOSSIL은 MS-DOS 호환 운영체제에서 전기 통신 프로그램의 직렬 통신을 허용하기 위한 표준 프로토콜이다. FOSSIL은 Fido Opus SEAdog Standard Interface Layer의 약자이다. Fido는 FidoNet을, Opus는 Opus-CBCS BBS를, SEAdog는 FidoNet 호환 메일러를 의미한다. FOSSIL 프로토콜을 정의하는 표준 문서는 FidoNet 기술 표준 위원회에서 관리한다.
직렬 장치 드라이버.
"FOSSIL 드라이버"는 단순히 통신 장치 드라이버이다. 초기 FidoNet 시대에는 컴퓨터 하드웨어가 매우 다양했고, 소프트웨어가 직렬 인터페이스 하드웨어와 통신하는 방식에 대한 표준이 없었기 때문에 존재했다. FidoBBS의 초기 개발은 특정 종류의 기계에서만 작동했다. FidoBBS가 확산되기 시작하기 전에, 소프트웨어가 다른 기계에서 사용되려면 직렬 인터페이스 하드웨어와 통신하는 통일된 방법이 필요하다는 인식이 있었다. 이러한 필요성은 다른 통신 기반 소프트웨어에서도 분명했다. FOSSIL 사양은 이러한 통일된 방법을 제공하기 위해 1986년에 탄생했다. FOSSIL 표준을 사용하는 소프트웨어는 어떤 하드웨어에서 실행되든 동일한 인터럽트 함수를 사용하여 통신할 수 있었다. 이를 통해 개발자들은 하드웨어 인터페이스가 아닌 애플리케이션에 집중할 수 있었다.
FOSSIL 드라이버는 각 플랫폼의 직렬 인터페이스 하드웨어에 맞게 특별히 작성되었기 때문에 작동하는 하드웨어에 따라 다르다. FOSSIL 드라이버는 IBM PC 호환기종의 확산과 함께 더욱 유명해졌다. 이러한 기계는 어떤 형태의 DOS(Disk Operating System)를 실행했으며, 바이오스는 직렬 통신에 대한 지원이 매우 미흡하여 비트리비얼한 통신 작업의 요구 사항을 훨씬 미치지 못했다. 시간이 지남에 따라 MS-DOS 및 PC DOS가 일반적인 운영체제가 되었고 PC 호환 하드웨어가 지배적이었다.
두 가지 인기 있는 DOS 기반 FOSSIL 드라이버는 X00 및 BNU였다. 인기 있는 마이크로소프트 윈도우 기반 FOSSIL 드라이버는 프리웨어인 NetFoss이다. SIO는 인기 있는 OS/2 기반 FOSSIL 드라이버이다.
직렬 인터페이스 이외의 하드웨어를 위한 FOSSIL 드라이버.
FOSSIL 드라이버는 애플리케이션에 "모뎀처럼 보이게" 하여 다른 통신 하드웨어를 지원하도록 구현되기도 했다.
(직렬 포트를 전혀 사용하지 않는) 내부 ISDN 카드는 종종 FOSSIL 드라이버와 함께 제공되어 원래 모뎀 작동만을 위한 소프트웨어와 함께 작동할 수 있도록 했다.
존 클라크(John Clark, John Clarke)는 다음 사람을 가리킨다.
컴퓨터 과학에서 FINO는 유머러스한 스케줄링 알고리즘이다. 이는 전통적인 선입 선출 (FIFO) 및 후입 선출 (LIFO) 알고리즘과 반대로 first in, never out의 두문자어이다. 비슷한 두문자어는 first in, still here를 뜻하는 "FISH"이다.
FINO는 모든 예약된 작업을 영구적으로 보류하여 작동한다. 언제든 얼마나 많은 작업이 예약되든, 실제로 어떤 작업도 실행되지 않는다.
상태 저장 FINO 큐는 메모리 누수를 구현하는 데 사용될 수 있다.
FINO에 대한 첫 언급은 시그네틱스 25120 쓰기 전용 메모리 농담 데이터시트에 나타난다.
비트 지향 프로토콜(Bit-oriented protocol)은 전송되는 데이터를 의미가 없는 불투명한 비트 스트림으로 간주하는 통신 프로토콜이다. 제어 코드는 문자 대신 비트 시퀀스로 정의된다. 비트 지향 프로토콜은 프레임 내용에 관계없이 데이터 프레임을 전송할 수 있다. 이는 "비트 스터핑"이라고도 할 수 있다.
동기식 프레이밍 고급 데이터 링크 제어는 다음과 같이 작동할 수 있다.
바이트 지향 프로토콜(Byte-oriented protocol) 또는 바이트 지향 프레이밍 프로토콜(Byte-oriented framing protocol)은 "전체 바이트가 제어 코드로 사용되는 통신 프로토콜이다. 문자 지향 프로토콜이라고도 알려져 있다." 예를 들어 UART 통신은 바이트 지향적이다.
"문자 지향"이라는 용어는 문자의 개념이 바뀌었기 때문에 더 이상 사용되지 않는다. ASCII 문자는 정보량 면에서 1바이트(옥텟)에 해당한다. 컴퓨터 소프트웨어의 국제화와 함께 다양한 언어의 텍스트를 처리하기 위해 와이드 문자가 필요해졌다. 특히 UTF-8에서 유니코드 문자(또는 엄밀히 말하면 코드 포인트)는 1, 2, 3 또는 4바이트일 수 있으며, 유니코드의 다른 인코딩은 코드 포인트당 2바이트 또는 4바이트를 사용한다.
코드 포인트(code point) 또는 코드 위치(code position)는 테이블 내의 특정 위치로, 해당 위치에 의미가 할당된 것이다. 테이블은 1차원(열), 2차원(스프레드시트의 셀과 유사), 3차원(통합 문서의 시트) 등 여러 차원으로 존재할 수 있다.
기술적으로, 코드 포인트는 정량화된 n차원 공간의 고유한 위치로, 해당 위치에 의미론적 의미가 할당된다. 테이블은 이산적(정수)이고 양의 위치(1, 2, 3, 4이지만 분수는 아님)를 갖는다.
코드 포인트는 수많은 공식 정보 처리 및 통신 표준에서 사용된다. 예를 들어 ITU-T 권고 T.35는 통신 장비(원래 팩스 기계)가 제조 또는 작동 국가를 나타낼 수 있도록 하는 일련의 국가 코드를 포함한다. T.35에서 아르헨티나는 코드 포인트 0x07로, 캐나다는 0x20으로, 감비아는 0x41 등으로 표시된다.
문자 인코딩에서.
코드 포인트는 일반적으로 문자 인코딩에 사용되며, 여기서 코드 포인트는 특정 문자에 매핑되는 숫자 값이다. 문자 인코딩에서 코드 포인트는 일반적으로 단일 자소를 나타내며—대개 글자, 숫자, 문장 부호, 또는 공백 문자—때때로 기호, 제어 문자 또는 서식을 나타낸다. 주어진 인코딩/문자 세트 내의 모든 가능한 코드 포인트 세트는 해당 인코딩의 코드 공간을 구성한다.
예를 들어, 문자 인코딩 방식인 ASCII는 0hex에서 7Fhex 범위의 128개 코드 포인트를 포함하고, 확장 ASCII는 0hex에서 FFhex 범위의 256개 코드 포인트를 포함하며, 유니코드는 0hex에서 10FFFFhex 범위의 개 코드 포인트를 포함한다. 유니코드 코드 공간은 17개의 평면(기본 다국어 평면과 16개의 보조 평면)으로 나뉘며, 각 평면은 (= 216)개의 코드 포인트를 갖는다. 따라서 유니코드 코드 공간의 총 크기는 17 ×  = 이다.
유니코드에서 특정 비트 시퀀스를 코드 단위라고 부른다. UCS-4 인코딩의 경우 모든 코드 포인트는 4-바이트 (옥텟) 이진수로 인코딩되는 반면, UTF-8 인코딩에서는 서로 다른 코드 포인트가 1바이트에서 4바이트 길이의 시퀀스로 인코딩되어 자기 동기 코드를 형성한다. 자세한 내용은 유니코드 인코딩 비교를 참조하면 된다.
코드 포인트는 일반적으로 추상적인 문자에 할당된다. 추상 문자는 그래픽 글리프가 아니라 텍스트 데이터의 단위이다. 그러나 코드 포인트는 향후 할당을 위해 예약되거나(유니코드 코드 공간의 대부분은 할당되지 않음) 다른 지정된 기능이 부여될 수도 있다.
코드 포인트와 해당 추상 문자 간의 구별은 유니코드에서는 뚜렷하지 않지만, 단일 코드 공간에 대해 수많은 코드 페이지가 존재할 수 있는 다른 많은 인코딩 방식에서는 분명하다.
코드 포인트의 개념은 디지털 정보 처리 및 디지털 통신의 초기 표준으로 거슬러 올라간다.
유니코드에서 코드 포인트는 1980년대 문자 인코딩 개발자들이 직면했던 어려운 수수께끼에 대한 유니코드의 해결책의 일부이다. 만약 더 큰 문자 세트를 수용하기 위해 문자당 비트를 더 추가했다면, 그 설계 결정은 당시 컴퓨터 사용자 대다수를 차지했던 로마자 사용자의 경우 추가 비트가 항상 0으로 채워질 것이기 때문에, 당시 부족했던 컴퓨팅 자원의 용납할 수 없는 낭비가 되었을 것이다. 코드 포인트는 문자와 특정 비트 시퀀스 간의 직접적인 일대일 대응이라는 오래된 개념을 깨뜨림으로써 이 문제를 피한다.
테스트 벤치(test bench) 또는 테스팅 워크벤치(testing workbench)는 설계 또는 모델의 정확성이나 건전성을 확인하는 데 사용되는 환경이다.
이 용어는 전자 장치 테스트에서 유래되었는데, 엔지니어가 오실로스코프, 멀티미터, 납땜 인두, 와이어 커터 등 측정 및 조작 도구를 갖춘 실험대에서 수동으로 피시험 장치 (DUT)의 정확성을 확인하는 방식이었다.
소프트웨어, 펌웨어 또는 하드웨어 공학의 맥락에서 테스트 벤치는 개발 중인 제품을 소프트웨어 및 하드웨어 도구의 도움으로 테스트하는 환경이다. 소프트웨어는 테스트 벤치와 작동하도록 일부 경우 약간 수정되어야 할 수 있지만, 신중한 코딩을 통해 변경 사항을 버그 없이 쉽게 되돌릴 수 있다.
"테스트 벤치"라는 용어는 하드웨어 기술 언어를 사용한 디지털 설계에서 DUT를 인스턴스화하고 테스트를 실행하는 테스트 코드를 설명하는 데 사용된다.
"테스트 벤치"의 추가적인 의미는 격리되고 통제된 환경으로, 생산 환경과 매우 유사하지만 일반 대중, 고객 등에게는 숨겨지거나 보이지 않는 환경이다. 따라서 최종 사용자가 관여하지 않기 때문에 변경 사항을 안전하게 적용할 수 있다.
타이머 코어레싱(Timer coalescing)은 중앙 처리 장치 (CPU) 전력 소비를 줄이는 컴퓨터 시스템 에너지 절약 기술로, 프로세스 기동 동기화에 사용되는 소프트웨어 타이머의 정확도를 낮춰 CPU가 유휴 상태로 진입 및 종료하는 상대적으로 전력 소모가 큰 작업을 수행해야 하는 횟수를 최소화한다.
아치 허드(Arch Hurd)는 아치 리눅스 배포판에 포함된 리눅스 커널 대신 GNU 허드 커널을 사용하는 GNU 운영체제 배포판이다.
아치 허드 프로젝트는 2010년 1월 아치 리눅스 포럼 스레드에서 시작되었고, 많은 기여와 함께 몇 주 만에 가상 머신에서 부팅할 수 있는 수준까지 발전했다. 이 프로젝트는 허드 상에서 아치 리눅스 환경(BSD 스타일 init 스크립트, i686 최적화 패키지, pacman 패키지 관리자 사용, 롤링 릴리스 및 KISS 설정)을 제공하는 것을 목표로 하며, 충분히 안정적으로 사용할 수 있는 수준을 지향한다.
아치 허드는 현재 안정적인 상태가 아니다. 운영체제 다운로드 이미지는 존재하지 않지만, 이전에는 Arch Hurd LiveCD에서 호스팅되었다. 하지만, 운영체제의 재업로드 버전을 찾을 수 있으며 사용자는 데비안 GNU/허드를 통해 Chroot 작업을 수행하여 사용할 수 있다.
적은 개발팀에도 불구하고, 아치 허드는 설립 이후 많은 발전을 이루었다. 실제 하드웨어에서 부팅하는 것, 기본적인 웹 서버를 위한 모든 것을 패키징하는 것, 그리고 비공식 그래픽 라이브CD를 제작하는 것 등이 있다.
2011년 6월, 아치 허드는 허드용 리눅스 드라이버 프레임워크인 장치 드라이버 환경(DDE)의 성공적인 통합을 발표했는데, 이는 배포판의 네트워크 하드웨어 지원을 개선하고 거의 사용할 수 있는 수준으로 만들었다.
기준으로, 공식 패키지는 2019년 5월에 마지막으로 업데이트되었고, Arch Hurd 웹사이트의 최신 메시지는 2021년 5월 25일자이다. Git 저장소에서는 여전히 개발 활동이 진행되고 있다.
AOS/VS II는 데이터 제너럴 32비트 MV/Eclipse 컴퓨터용으로 단종된 운영체제이다.
AOS/VS II 운영 체제는 1988년에 출시되었으며 원래 AOS/VS 운영 체제의 단순히 개정 8.00이었다. 그러나 이 시스템은 원래 AOS 및 AOS/VS 파일 시스템과 호환되지 않는 새로운 파일 시스템을 도입했으며 접근 제어 목록(ACL) 그룹과 같은 새로운 기능도 포함했다. 일부 고객은 새 파일 시스템으로 업그레이드하거나 새 하드웨어에 투자하는 것을 원하지 않았기 때문에 데이터 제너럴은 AOS/VS의 "불멸" 개정에 대한 버그 수정 지원을 계속하기로 합의했으며, 이는 통칭적으로 AOS/VS "클래식"으로 알려지게 되었다. 반면 새로운 개발은 개정 번호를 1.00으로 되돌린 AOS/VS II로 진행될 예정이었다.
VS-클래식(개정 7.7x)과 VS-II(개정 3.2x)는 둘 다 구식이 되었지만 2000년 문제를 극복하도록 업데이트되었다.
AOS/VS II의 다른 새로운 기능으로는 전체 TCP/IP 스택, NFS 지원, 링-1을 사용한 확장된 커널 주소 공간 및 논리 디스크 수준 사용자 데이터 캐시가 있었다. /VS (클래식)는 파일 시스템 메타데이터 캐시가 있었지만 사용자 데이터 캐시는 없었다.
데이터 제너럴 AOS(Data General AOS, 어드밴스트 오퍼레이팅 시스템, Advanced Operating System의 약자)는 데이터 제너럴 16비트 이클립스 C, M, S 미니컴퓨터용 운영체제 제품군의 이름이었고, 이어서 AOS/VS와 AOS/RT32 (1980)와 나중에 32비트 이클립스 MV 라인용 AOS/VS II (1988)가 출시되었다.
AOS/VS는 이클립스 MV 하드웨어의 8-보호 링 아키텍처를 활용했으며, 링 7은 가장 적은 권한을, 링 0은 가장 많은 권한을 가졌다. AOS/VS 커널은 링 0에서 실행되었고 가상 주소 변환과 관련된 데이터 구조에 링-1 주소를 사용했다. 링 2는 사용되지 않았고 커널의 향후 사용을 위해 예약되었다. AOS/VS 커널에 대한 시스템 호출 유효성 검사, 일부 I/O 버퍼링 및 많은 호환성 기능을 수행하는 에이전트는 각 프로세스의 링 3에서 실행되었다. 링 4는 INFOS II DBMS와 같은 다양한 D.G. 제품에서 사용되었다. 링 5와 6은 사용자 프로그램에서 사용하도록 예약되었지만 MV/UX 내부 링 에뮬레이터 및 링 5를 사용한 오라클과 같은 대형 소프트웨어를 제외하고는 거의 사용되지 않았다. 모든 사용자 프로그램은 링 7에서 실행되었다.
AOS 소프트웨어는 경쟁 PDP-11 운영체제보다 훨씬 더 발전했다. 16비트 AOS 애플리케이션은 32비트 이클립스 MV 라인에서 AOS/VS 및 AOS/VS II 아래에서 기본적으로 실행되었다. AOS/VS(Advanced Operating System/Virtual Storage)는 가장 일반적으로 사용되는 DG 소프트웨어 제품이었으며, 복잡한 스크립팅, DUMP/LOAD 및 기타 사용자 지정 구성 요소를 허용하는 명령줄 인터프리터 (CLI)를 포함했다.
16비트 버전의 CLI는 Xyzzy(발음은 "매직")를 기념하기 위한 이스터 에그를 포함하고 있는 것으로 유명하다. 이것은 외부적으로 AOS/VS 32비트 운영체제로 알려지게 된 것의 내부 코드명이었다. 사용자가 "xyzzy"라는 명령어를 입력하면 CLI에서 "아무 일도 일어나지 않는다"는 응답을 받았다. AOS/VS II에서 32비트 버전의 CLI가 출시되었을 때, 같은 명령어는 대신 "두 배 더 많은 일이 일어난다"고 보고했다.
AOS/VS에서 호스팅되는 System V.2 유닉스의 수정 버전인 MV/UX도 제공되었다. 이클립스 MV 라인과 나중에 88K 및 X86 AViiON 머신을 위해 DG/UX라고 불리는 시스템 V 유닉스의 수정 버전이 만들어졌다.
AOS 및 AOS/VS 커널은 전적으로 어셈블리어로 작성되었다. 운영 체제 릴리스에 포함된 AOS 및 AOS/VS 유틸리티의 거의 모든 부분은 ALGOL/60 프로그래밍 언어의 변형인 DG/L로 작성되었다. 초기에 AOS/VS 유틸리티는 AOS 소스 개발을 면밀히 추적했다. AOS/VS가 성숙함에 따라 많은 DG 제공 유틸리티는 32비트 주소 공간을 활용하고 어셈블리어에 대한 종속성을 줄이기 위해 다시 작성되었으며, 종종 AOS 선조들에 비해 기능, 성능 및 신뢰성에서 상당한 증가를 가져왔다.
BLIS/COBOL은 코볼로 작성된 단종된 운영체제였다. 합리적으로 널리 받아들여진 유일한 시스템이다. 코볼로 작성된 비즈니스 응용 프로그램을 컴파일하도록 최적화되었다. BLIS는 데이터 제너럴 노바 및 데이터 제너럴 이클립스 16비트 미니컴퓨터에서 사용할 수 있었다. 이 시스템은 IPI(Information Processing, Inc.)가 판매했으며, 1970년대와 80년대에 내셔널 컴퓨터 컨퍼런스에서 이 제품을 정기적으로 전시했다. 지원되는 사용자 수와 기능에 따라 가격은 US$830에서 $10,000 사이였다. 1977년 IPI는 전 세계적으로 100개 이상의 시스템이 운영 중이라고 자랑했다.
1985년까지 IBM 개인용 컴퓨터용 버전인 PC-BLIS가 존재했다.
원래 대부분의 운영체제는 특정 프로세서 또는 프로세서 제품군을 위해 어셈블리어로 작성되었다. 어셈블리어 이외의 운영체제는 비교적 느렸지만, 수정 및 복구가 더 쉬웠다. C 프로그래밍 언어가 어셈블리어와 유사한 저수준 기능을 가지는 이유 중 하나는 운영체제를 작성하는 데 사용하려는 초기 의도 때문이었다. 유사한 목표로 IBM의 PL/S 개발이 이루어졌다. 운영체제 개발에 일부 문제를 야기했던 코볼의 고급스러운 특성은 BLIS에서 부분적으로 해결되었는데, 이는 BLIS가 코볼에 맞춰 의도적으로 최적화되었기 때문이다.
BESYS(Bell Operating System)는 벨 연구소에서 IBM 704 컴퓨터를 위해 1957년에 일괄 처리 운영체제로 처음 구현된 초기 컴퓨팅 환경이었다.
벨 연구소는 "704의 내부 속도, 온라인 단위 기록 장비의 느림, 그리고 독립형 사용과 관련된 수동 작업의 본질적인 느림 사이의 명확한 불일치"를 인식했기 때문에 이 시스템을 개발했다. 드러먼드에 따르면, BESYS라는 이름은 일반적으로 BEll SYStem의 약자로 알려져 있지만, 실제로는 벨 전화 연구소(Bell Telephone Laboratories, Murray Hill, NJ)에 미리 존재하던 SHARE 할당 설치 코드 BE와 시스템 소프트웨어에 할당된 SHARE 코드 SYS를 연결한 것이다.
이 시스템의 목표는 다음과 같았다.
시스템 BESYS-1의 초기 버전은 1957년 10월 16일까지 사용되었다. 이 시스템은 조지 H. 밀리와 그웬 한센이 완다 리 매멀과 함께 만들었으며 IBM의 FORTRAN과 유나이티드 에어크래프트의 심볼릭 어셈블리 프로그램(Symbolic Assembly Program, SAP) 프로그래밍 언어를 활용했다. 이 시스템은 천공 카드에서 시작되어 종이 및 천공 카드에 인쇄하기에 적합한 결과를 생성하는 많은 작업을 효율적으로 처리하도록 설계되었다. 또한 자기 테이프와 자기 디스크 저장 장치에 저장된 데이터를 처리하는 기능도 제공했다. 일반적으로 천공 카드 및 인쇄 처리는 주변 전자 회계 기계, IBM 1401 컴퓨터 및 최종적으로 직접 연결된 컴퓨터에 의해 오프라인으로 처리되었다.
벨 연구소에서 실제로 사용된 첫 번째 시스템은 BESYS-2였다. 이 시스템은 자기 테이프에 상주했으며, 메모리의 가장 낮은 64 (36비트) 워드와 가장 높은 4K 워드를 차지했다. 상위 4K 워드에는 모니터의 상주 부분이 포함되어 있었으며, 필요하면 사용자 프로그램을 위해 추가 코어를 확보하기 위해 자기 드럼으로 부분적으로 스왑될 수 있었다.
"BESYS는 편리한 입출력과 통합 디스크 파일 저장 기능을 제공하는 복잡한 소프트웨어 패키지였다."
내부 사용.
BESYS는 벨 연구소의 많은 부서에서 10년 이상 광범위하게 사용되었다. 이 시스템은 SHARE 조직을 통해 다른 사람들에게 무료로 또는 공식적인 기술 지원 없이 제공되었다.
BESYS 버전.
BESYS 환경 버전(BESYS-3 (1960), BESYS-4 (1962), BESYS-5 (1963), BESYS-7 (1964), 그리고 BE90 (1968))은 기본 컴퓨터가 IBM 709X 계열로 전환됨에 따라 구현되었다. BESYS 개발은 1969년 벨 연구소가 IBM 시스템/360으로 이동하면서 중단되었다. 이 기간 동안 BESYS 개발 프로젝트의 책임자는 조지 L. 볼드윈이었다.
REX OS(REX Operating System, Real-time Executive Operating System)는 퀄컴이 ARM 프로세서 기반 휴대폰 Dual-Mode Subscriber Station (DMSS) 또는 Advanced Mode Subscriber Software (AMSS) 개발을 위해 개발한 실시간 운영체제 (RTOS)이다. 2007년 기준으로 대부분의 한국 휴대폰은 REX에서 실행되었다.
REX는 두 가지 운영체제의 조합이다. 임베디드 마이크로커널과 이구아나에 퀄컴과 HTC의 광범위한 수정 및 확장이 이루어졌다.
원래 인텔 80186용으로 개발되었으나, 이후 ARM으로 포팅되었고 X86 아키텍처는 더 이상 지원되지 않는다. REX는 POSIX를 준수하지 않거나 오픈 소스 소프트웨어가 아니며 사용하려면 퀄컴의 사유 소프트웨어 사용권이 필요하다.
2012년 현재 활발히 개발되거나 판매되는 것으로 보이지는 않지만, 삼성 SPH-M300과 같이 선불 요금 고객이 주로 사용하는 현재 또는 최근 판매되는 보급형 휴대폰에 사용되고 있다.
REX는 다음과 같은 기능을 가진 RTOS이다.
REX는 메모리 보호 기능은 제공하지 않지만 메모리 관리 기능은 제공한다.
클라우드리눅스 OS(CloudLinux OS)는 상용 리눅스 배포판으로, 공유 호스팅 제공업체에 판매된다. 소프트웨어 회사 CloudLinux, Inc.에서 개발한다. CloudLinux OS는 CentOS 운영체제를 기반으로 하며, OpenVZ 커널과 rpm 패키지 관리자를 사용한다.
클라우드리눅스 OS는 OpenVZ 커널을 기반으로 수정된 커널을 제공한다. 주요 기능은 자체 CPU, 메모리, IO, IOPS, 프로세스 수 및 기타 제한이 있는 별도의 환경인 LVE(Lightweight Virtual Environment)이다. 클라우드리눅스 OS로 전환은 커널을 설치하고 yum 저장소를 전환하며 LVE가 작동하도록 기본 패키지를 설치하는 제공된 codice_1 스크립트를 통해 수행된다. 설치 후 서버는 새로 설치된 커널을 로드하기 위해 재부팅이 필요하다. 클라우드리눅스 OS는 기존 패키지를 수정하지 않으므로 이전 커널을 일반적인 방식으로 부팅할 수 있다.
AlmaLinux의 생성.
CloudLinux는 CentOS의 대체품으로 의도된 무료 운영체제인 AlmaLinux OS의 첫 번째 베타 버전을 2021년 2월 1일에 출시했다.
2021년 3월 30일, 첫 번째 안정 버전 출시와 같은 날 CloudLinux는 프로젝트의 개발 및 거버넌스 책임을 AlmaLinux OS 재단에 이관했다. CloudLinux는 프로젝트에 연간 100만 달러의 자금을 지원할 것을 약속했지만, 더 이상 프로젝트를 소유하지 않는다.
IBSYS는 IBM이 IBM 709, IBM 7090, IBM 7094 컴퓨터와 함께 제공했던 단종된 테이프 기반 운영체제이며, IBM 7040 및 IBM 7044 컴퓨터와 함께 제공된 상당히 다르지만 유사한 운영체제이다. IBSYS는 FORTRAN 모니터 시스템 (FMS)과 (더 가능성이 높은) 벨 연구소의 "BESYS"를 기반으로 했으며, SHARE 운영체제를 기반으로 하지는 않았다.
IBSYS는 $EXECUTE 카드에서 9PAC, FORTRAN 및 IBSFAP와 같은 몇 가지 이전 컴퓨터 언어 컴파일러 및 어셈블러를 직접 지원했다. 새로운 언어 처리기는 IBJOB에서 실행되었다.
IBM은 나중에 7040/7044용으로 IBM 7040/7044 운영체제 (16K/32K) 7040-PR-150을, IBM 1410/IBM 7010용으로 IBM 1410/7010 운영체제 1410-PR-155를 제공했다.
IBSYS 시스템 슈퍼바이저.
IBSYS 자체는 상주 모니터 프로그램으로, 개별 작업의 프로그램 및 데이터 카드 덱 사이에 놓인 제어 카드 이미지를 읽는다. IBSYS 제어 카드는 1열에 "$"로 시작하며, 즉시 작업 설정 및 실행에 필요한 다양한 IBSYS 유틸리티 프로그램을 선택하는 제어 이름이 뒤따른다. 이러한 카드 덱 이미지는 일반적으로 카드 판독기에서 직접 읽는 것이 아니라 오프라인에서 준비된 자기 테이프에서 읽는다.
IBJOB 프로세서.
IBJOB 프로세서는 IBSYS 시스템 슈퍼바이저에서 실행되는 서브시스템이다. 컴파일, 실행 등을 요청하는 제어 카드를 읽는다. 지원되는 언어에는 코볼, Commercial Translator (COMTRAN), 포트란 IV (IBFTC) 및 Macro Assembly Program (IBMAP)이 있다.
IBM RT PC(RISC Technology Personal Computer)는 1986년에 IBM이 선보인 워크스테이션 제품군이다. 이 제품은 축소 명령어 집합 컴퓨터(RISC) 아키텍처를 기반으로 한 IBM 최초의 상업용 컴퓨터였다. RT PC는 IBM 리서치의 801 실험용 미니컴퓨터(801은 최초의 RISC 컴퓨터였다)에서 개척된 기술을 상용화한 IBM의 독점 ROMP 마이크로프로세서를 사용한다. RT PC는 AIX, AOS(Academic Operating System), 픽의 세 가지 운영 체제를 실행한다.
RT PC의 사양은 경쟁사의 동시대 워크스테이션과 비교할 때 "인상적이지 못하다"는 평가를 받았지만, 특히 IBM이 "진지한 경쟁자"로서 "상당한 존경을 받을 만하다"고 여겨졌다. 경쟁사 제품보다 성능이 약 18개월 뒤처졌음에도 불구하고, IBM이 회사의 뛰어난 기술력으로 빠르게 따라잡을 수 있을 것이라는 전망 때문이었다. 이러한 성능적 한계로 인해 RT PC는 상업적으로 큰 성공을 거두지 못했다. 이에 IBM은 1990년에 새로운 IBM 독점 RISC 프로세서인 POWER1을 사용하는 IBM RS/6000 워크스테이션을 출시하며 대응했다. 모든 RT PC 모델은 1991년 5월에 단종되었다.
두 가지 기본 유형이 생산되었다. 바닥에 세워두는 책상 옆 타워형(IBM 6150)과 데스크톱형(IBM 6151)이다. 두 유형 모두 프로세서 카드용 특수 보드 슬롯과 기계별 RAM 카드를 갖추고 있었다. 각 기계에는 프로세서 슬롯 1개, 코프로세서 슬롯 1개, RAM 슬롯 2개가 있었다.
프로세서 카드는 세 가지 버전이 있었다.
모든 RT PC는 최대 16공백MB의 메모리를 지원했다. 초기 모델은 사용된 DRAM IC의 용량 때문에 4공백MB로 제한되었고, 후기 모델은 최대 16공백MB까지 가능했다. I/O는 8개의 ISA 버스 슬롯으로 제공되었다. 저장 공간은 40공백MB 또는 70공백MB 하드 드라이브로 제공되었으며, 300공백MB까지 업그레이드할 수 있었다. 외부 SCSI 캐비닛을 사용하여 더 많은 저장 공간을 제공할 수 있었다. 또한 마우스와 720x512 또는 1024x768 픽셀 주소 지정 가능한 디스플레이, 4공백Mbit/s 토큰링 네트워크 어댑터 또는 10BASE2 이더넷 어댑터가 표준으로 제공되었다.
컴퓨터 지원 설계(CAD) 프로그램인 CADAM을 실행하기 위해 IBM 5080 또는 5085 그래픽 프로세서를 연결할 수 있었다. 5080과 5085는 RT PC 옆에 놓였을 대형 캐비닛에 담겨 있었다. 5080은 1,024x1,024 픽셀의 IBM 5081 디스플레이와 함께 사용되었다.
6152 학술 시스템.
6152 학술 시스템은 PS/2 모델 60에 RISC 어댑터 카드(ROMP, 지원 IC, 최대 8공백MB 메모리가 포함된 마이크로 채널 보드)를 추가한 것이었다. 이를 통해 PS/2는 AOS용으로 컴파일된 ROMP 소프트웨어를 실행할 수 있었다. AOS는 LAN TCP/IP 인터페이스를 통해 AOS를 실행하는 RT PC에서 다운로드되었다.
RT 설계의 새로운 측면 중 하나는 마이크로커널을 사용했다는 점이다. 키보드, 마우스, 디스플레이, 디스크 드라이브 및 네트워크는 모두 가상 자원 관리자(VRM)라는 마이크로커널에 의해 제어되었으며, 이를 통해 여러 운영 체제를 동시에 부팅하고 실행할 수 있었다. Alt-Tab 키 조합을 사용하여 한 운영 체제에서 다음 운영 체제로 "핫키" 전환이 가능했다. 각 OS는 차례로 키보드, 마우스 및 디스플레이를 점유하게 되었다. AIX 버전 2와 픽 운영 체제 모두 이 마이크로커널로 포팅되었다. 픽은 통합 운영 체제이자 데이터베이스라는 점에서 독특했으며, 다양한 회계 애플리케이션을 실행했다. 소매상인들에게 인기가 많았고, 약 4,000대 판매를 기록했다.
RT의 주요 운영 체제는 AIX 버전 2였다. AIX v2 커널의 상당 부분은 PL/I 프로그래밍 언어의 변형으로 작성되었는데, 이는 AIX v3로 마이그레이션하는 과정에서 문제가 되었다. AIX v2는 완전한 TCP/IP 네트워킹 지원과 SNA를 포함했으며, 두 가지 네트워킹 파일 시스템을 포함했다. 하나는 썬 마이크로시스템즈에서 라이선스를 받은 NFS였고, 다른 하나는 IBM 분산 서비스(DS)였다. DS는 SNA 위에 구축되어 IBM 미드레인지 AS/400 및 메인프레임 시스템의 DS와 완전히 호환된다는 특징이 있었다. 그래픽 사용자 인터페이스의 경우, AIX v2는 MIT의 X 윈도 시스템 X10R3 및 이후 X10R4, X11 릴리스와 Athena 위젯 세트를 함께 제공했다. C 및 포트란 프로그래밍 언어용 컴파일러가 제공되었다.
일부 RT PC는 RT PC용 4.3BSD 유닉스의 IBM 포트인 AOS(Academic Operating System)와 함께 출하되기도 했다. 이는 IBM 교육 할인 대상인 미국 대학에 일반적인 RT PC 운영 체제인 AIX의 대안으로 제공되었다. AOS는 4.3BSD에 몇 가지 추가 기능을 더했는데, 특히 NFS와 거의 ANSI C를 준수하는 C 컴파일러가 포함되었다. 이후 4.3BSD-Reno에서 파생된 AOS 버전이 존재했지만 널리 배포되지는 않았다.
RT는 브라운 대학교의 한 그룹이 X 버전 9를 이 시스템으로 포팅하면서 X 윈도 시스템 개발에 중요한 발판을 마련했다. RT에서 정렬되지 않은 데이터를 읽는 데 문제가 발생하여 호환되지 않는 프로토콜 변경이 필요했고, 이는 1985년 후반에 버전 10으로 이어졌다.
판매 및 시장 반응.
1986년 1월 RT PC가 출시되었을 때, 이 제품은 기존 공급업체들의 여러 워크스테이션들과 경쟁했다. 아폴로 컴퓨터 도메인 시리즈 3000, DEC 마이크로VAX II, 그리고 썬 마이크로시스템즈 썬-3 등이 그것이었다. 컴퓨터월드는 경쟁사들이 IBM의 제품이 자신들의 제품보다 싸거나 빠르지 않다는 사실에 "안도의 한숨을 쉬었다"고 전했다. 분석가들은 RT PC가 너무 비싸고(CAD/CAM 시스템의 경우 거의 40,000달러) 경쟁사 제품을 모방했으며 그래픽과 네트워킹 기능이 인상적이지 않다고 말했다. 그러나 IBM이 워크스테이션 시장에서 계속 경쟁할 것으로 예상했다.
RT의 성능은 다른 동시대 유닉스 워크스테이션과 비교했을 때 뛰어나지 않았다. 특히 부동 소수점 성능이 좋지 않았고, 부동 소수점 제곱근 루틴의 버그가 발견되면서 제품 수명 중간에 스캔들이 발생하기도 했다. 퍼스널 컴퓨터 월드는 "6150을 통해 얻을 수 있는 것이 무엇인지 알기 어렵다. 다른 어떤 유닉스 시스템을 다중 사용자 애플리케이션 실행용으로, 저렴한 AT 클론을 단일 사용자 PC 애플리케이션 실행용으로 조합하여 얻을 수 없는 것이 없다"고 말했다. MIT의 프로젝트 아테나와 브라운 대학교의 정보 및 장학 연구소(Institute for Research in Information and Scholarship) 모두 RT가 다른 컴퓨터보다 열등하다고 평가했다.
많은 사람들은 RT가 IBM의 퍼스널 컴퓨터 라인에 속하는 컴퓨터라고 생각했다. 이러한 혼란은 초기 이름인 "IBM RT PC"에서 시작되었다. 처음에는 IBM조차도 이 제품이 IBM으로부터 처음에는 놀라울 정도로 지원을 받지 못했다는 점을 감안할 때 고성능 퍼스널 컴퓨터라고 생각했던 것 같다. 이는 IBM이 이 시스템에 부여한 판매 수수료 구조로 설명될 수 있는데, 영업사원들은 PC 판매와 유사한 수수료를 받았다. 일반적으로 20,000달러에 달하는 가격으로 구성된 모델은 판매하기 어려웠고, 합리적인 수수료의 부재는 IBM 영업팀의 관심을 잃게 했다.
RT 시스템의 평범한 처리 능력(처음 발표되었을 때)과 같은 해 말 다른 워크스테이션 공급업체들의 발표로 인해 업계 분석가들은 IBM의 방향에 의문을 제기했다. RT용 AIX는 1984년 9월 IBM PC용 PC/IX 이후 IBM이 유닉스를 판매하려는 또 다른 시도였다. 소프트웨어 패키지의 부족과 IBM의 때로는 미흡한 AIX 지원, 그리고 전통적인 사실상의 유닉스 운영 체제 표준과의 때로는 특이한 변화들로 인해 대부분의 소프트웨어 공급업체들은 RT와 AIX를 채택하는 데 느렸다. RT는 주로 CAD/CAM 및 카티아 시장에서 자리를 잡았으며, 특히 AOS 발표와 교육 커뮤니티에 대한 상당한 할인 이후 과학 및 교육 분야에서도 일부 진출했다. Pick OS를 실행하는 RT는 Pick OS의 강력한 데이터베이스, 회계 시스템 및 일반 비즈니스 지원 덕분에 상점 제어 시스템으로도 사용되었다. RT는 또한 SNA 및 DS 지원 덕분에 IBM의 대형 메인프레임과 일부 POS 단말기, 상점 제어 시스템 및 기계 공장 제어 시스템 간의 인터페이스 시스템으로도 잘 활용되었다.
생산 기간 동안 약 23,000대의 RT가 판매되었으며, 이 중 약 4,000대는 IBM의 개발 및 판매 조직으로 들어갔다. Pick OS 판매는 약 4,000대를 차지했다.
1990년까지 IBM은 워크스테이션 시장의 1.8%만을 차지했다. IBM은 1990년 2월에 훨씬 더 좋은 반응을 얻은 RS/6000을 발표했다. 인포월드는 "재앙적"이었던 RT PC 이후 이 회사의 성공이 중요하다고 말했다. RT PC는 "경쟁사들 사이에서 오직 웃음만 자아냈다"고 말했다.
NSFNET 백본의 일부로서.
1987년, "NSF는 IBM이 ‘병렬 라우터’로 구현한 24대의 RT-PC를 병렬로 사용하여 슈퍼컴퓨팅 센터 간 T1 백본을 구현하기 시작한다. T1 아이디어가 너무 성공적이어서 백본의 T3 속도에 대한 제안이 시작된다. 1980년대 인터넷 역사
NSFNET은 인터넷의 전신이었다. 1988년 7월부터 1992년 11월까지 NSFNET의 T1 인터넷 백본 네트워크는 여러 RT PC(일반적으로 9대)로 구축된 라우터를 토큰링 LAN으로 상호 연결하여 사용했다.
이 항목은 RT/PC FAQ의 텍스트를 포함한다.
사촌혼(四寸婚, )은 사촌(즉 같은 조부모를 공유하거나 이에 상당한 친연 관계인 사람) 사이에 혼인하는 것을 말한다. 이 관행은 역사적으로 흔했으며 현재도 문화권에 따라 널리 행해지고 있다. 그러나 문화적 이유 또는 근친상간에 의한 여러 위험에 대한 우려로 일부 국가 또는 지역에서는 금지 내지 제한이 이루어지고 있다. 근친혼 중 가장 보편적인 형태이기 때문에 문화별 친족 구조를 연구하는 인류학에서는 중요한 연구 분야 중 하나이기도 하다.
어떤 문화에서는 사촌 결혼이 이상적인 것으로 여겨져 적극적으로 장려되나 어떤 곳에서는 기피되거나 금기시된다. 현대에는 한국, 북한, 중국, 필리핀, 인도의 일부 지역(힌두교도에 한해), 일부 발칸 국가, 벨기에, 리투아니아, 미국의 30개 주에서 법적으로 금지되어 있다. 특히 미국의 8개 주에서는 사촌혼이 범죄로 규정되어 있는데, 이것은 세계적으로 유일한 사례이다. 영어에서 cousin marriage라 하면 second cousin이라 지칭되는 6촌 간의 혼인까지 포함할 수 있으므로 '사촌혼'과 의미가 일치하지는 않는다.
BOS/360(Basic Operating System/360)은 초기 IBM 시스템/360 운영체제였다.
BOS는 뉴욕주 엔디콧에 있는 IBM 일반 제품 사업부(GPD)가 개발한 네 가지 System/360 운영체제 버전 중 하나로, OS/360이 가장 작은 시스템에서 실행될 수 없다는 것이 명백해졌을 때 System/360 제품군의 저가형 시스템에서 발생한 공백을 메우기 위해 개발되었다. BPS(베이직 프로그래밍 서포트)는 최소 8KB의 주 기억 장치와 디스크 없이 실행되는 시스템을 위해 설계되었다. BOS는 최소 8KB의 디스크 시스템과 1개의 2311 디스크 드라이브를 위해 만들어졌다. DOS와 TOS는 최소 16KB의 디스크(DOS) 또는 테이프 드라이브만 있는(TOS) 시스템을 위해 BOS에서 개발되었다.
BOS는 OS/360보다 거의 2년 전인 1965년 10월에 출시되었으며, 따라서 BOS는 디스크 기반으로 마케팅된 기계에 출시 당시 유일하게 사용 가능한 디스크 기반 운영체제였다.
BOS는 다음 구성 요소로 구성되었다.
IBM 1070 프로세스 통신 감독자.
IBM 1070 프로세스 통신 감독자는 BOS "일반적인 물리적 및 논리적 I/O 작업(예: 카드, 디스크 등)을 처리하기 위해 BOS 감독자에 의존하여, PC 감독자는 사용자 프로그램의 프로세스 제어 측면에 특화되어 있다"는 확장으로 실행되는 전용 프로세스 제어 시스템이었다.
IBM 시분할 시스템 TSS/360은 시분할 운영체제의 일종으로, System/360 메인프레임 계열의 특수 모델인 모델 67 전용으로 설계되었지만 현재는 단종되었다. 1967년 제한된 수의 고객에게 시험적으로 제공되었지만, IBM에 의해 공식적으로 지원되는 제품으로 출시되지는 않았다. TSS는 여러 새로운 기능을 개척했으며, 그중 일부는 나중에 MVS와 같은 더 인기 있는 시스템에 등장했다. TSS는 System/370 및 303x 시스템으로 마이그레이션되었지만, 많은 발전과 새로운 기능에도 불구하고 TSS는 기대를 충족시키지 못했고 결국 취소되었다. TSS/370의 상주 슈퍼바이저는 유닉스를 IBM 메인프레임으로 포팅하는 기반으로 사용되었다. TSS/360은 TSS/8 운영 체제 개발에도 영감을 주었다.
새로운 특징.
TSS/360은 긴밀하게 결합된 대칭형 다중 처리의 초기 구현 중 하나였다. 한 쌍의 모델 67 메인프레임은 공통 물리 메모리 공간을 공유하고, 커널 (및 애플리케이션) 코드의 단일 복사본을 실행했다. 한 프로세서에 의해 시작된 I/O 작업은 종료되어 다른 프로세서에서 인터럽트를 일으킬 수 있었다. 모델 67은 테스트 앤 셋(Test and Set)이라는 표준 360 명령어를 사용하여 코드 임계 구역에 락을 구현했다.
또한 위치 독립 코드를 사용하여 가상 메모리와 가상 머신을 구현했다.
TSS/360에는 "테이블 기반 스케줄러"의 초기 구현이 포함되어 있었다. 이 스케줄러는 현재 우선순위, 워킹 셋 크기, 지금까지 사용된 타임 슬라이스 수와 같은 매개변수가 있는 사용자 구성 테이블이었다. 커널은 스레드의 새 우선순위를 계산할 때 이 테이블을 참조했다. 이 기능은 나중에 Honeywell CP-V 및 IBM z/OS와 같은 다양한 시스템에 등장했다.
당시 운영체제 소프트웨어의 표준이었듯이, TSS/360 고객(예: 제너럴 모터스 연구소)에게는 운영체제 코드 및 개발 도구의 전체 소스에 대한 완전한 접근 권한이 주어졌다. 사용자 개발 개선 사항 및 패치는 공식 소스 코드에 자주 통합되었다.
TSS는 사용자에게 명령줄 인터페이스를 제공한다. 사용자는 명령 시스템과 상호 작용한다. 명령 형식은 codice_1로 구성된다. 명령 이름은 공백 없이 1~8자이다. 피연산자는 명령에 따라 선택 사항이며, 명령 이름과 하나 이상의 공백으로 구분해야 한다. 여러 피연산자는 탭 문자나 쉼표로 구분해야 한다. 명령줄은 계속할 줄 끝에 하이픈("-")을 입력하고 다음 줄 시작 부분에 계속할 내용을 입력하여 계속할 수 있다. 여러 명령은 세미콜론(";")으로 구분하여 한 줄에 작성할 수 있다. 명령줄에는 세미콜론으로 명령과 구분하고 작은따옴표(""")로 묶은 주석이 허용된다. 피연산자는 위치 또는 키워드일 수 있으며, "keyword=value" 형식이다.
시스템 명령은 7가지 범주로 나뉜다.
위치 독립 코드.
TSS는 위치 독립 코드의 초기 구현을 제공했다. 이는 서로 다른 프로세스가 단일 실행 파일의 사본을 실행할 수 있도록 하는 기능으로, 각 프로세스에서 다른 가상 주소에 매핑될 수 있다.
각 프로시저에는 읽기 전용 공용 CSECT, 쓰기 가능한 개인 프로토타입 섹션(PSECT) 및 쓰기 가능한 저장 영역(일반적으로 PSECT에 위치)이 있을 수 있다. 외부 프로시저 및 진입점의 주소 상수는 PSECT에 위치해야 한다. 동적 로더는 모든 프로세스에서 루틴을 동일한 가상 주소에 배치하지 않기 때문이다. 유형 I 링크 규칙을 따르는 프로그램은 일반적으로 진입 시 레지스터 13이 가리키는 저장 영역에 레지스터를 저장하고, 저장 영역의 19번째 워드에서 PSECT의 주소를 검색하며, 저장 영역을 새 저장 영역에 연결하고 새 저장 영역의 주소를 레지스터 13에 넣을 책임이 있다. 유형 I 링크 규칙을 따르는 호출자는 루틴에 대한 V-상수를 일반 레지스터 15(GR15)에 로드하고 루틴을 호출하기 전에 GR13이 가리키는 저장 영역의 19번째 워드에 루틴의 PSECT에 대한 R-상수를 복사한다.
동적 로더가 프로그램을 로드하면 PSECT의 사본을 만들고 현재 프로세스 내에서 할당된 가상 주소를 반영하도록 주소 상수를 재배치하므로 프로그램의 각 사용자는 PSECT의 고유한 사본을 갖게 된다.
동적 로더는 첫 번째 페이지 폴트가 발생할 때까지 프로그램 페이지를 로드하거나 주소 상수를 해결하지 않는다.
TSS/360은 성능 및 신뢰성 문제와 OS/360과의 호환성 부족으로 어려움을 겪었지만, 이러한 문제들은 결국 해결되었다. IBM은 멀틱스와 경쟁하기 위해 대규모 프로그래머 팀과 함께 매우 공격적인 일정으로 TSS를 개발하려고 했다. 1967년까지 TSS/360이 OS/360과 같은 종류의 지연을 겪고 있다는 것이 분명해졌다. 1968년 2월, SHARE 30 회의 당시 18개의 S/360-67 사이트가 TSS를 실행하려고 시도하고 있었다. 회의 중에 IBM은 "파란 편지"를 통해 TSS/360이 공식적으로 중단될 것임을 발표했다 이는 시분할 커뮤니티에 큰 타격이었다. 이 결정은 일시적으로 번복되었고, TSS/360은 1971년까지 공식적으로 취소되지 않았다. 그러나 TSS/360은 기존 TSS/360 고객들에게 잠정적인 조치로 한동안 조용히 제공되었다.
TSS/360이 취소된 후, IBM은 주요 노력을 OS/360의 시분할 모니터인 TSO에 집중했다. 다른 여러 그룹은 S/360-67을 위한 덜 야심적이고 더 성공적인 시분할 시스템을 개발했는데, 특히 IBM의 케임브리지 과학 센터의 CP-67은 초기 가상 머신 모니터로서 VM/370으로 발전했으며, 미시간 대학교의 MTS와 스탠퍼드 대학교의 ORVYL이 있었다. IBM은 또한 기존 TSS/360 고객을 위한 마이그레이션 경로로 PRPQ인 TSS/370을 제공했으며, 이는 여러 차례 릴리스되었다.
아프가니스탄-파키스탄 충돌은 아프가니스탄과 파키스탄 간의 국경을 넘는 공습과 총격전으로 구성된 일련의 지속적인 무력 충돌이다. 이 분쟁에는 별도로 발루치스탄 해방군(BLA)과 파키스탄 탈레반도 관련되어 있다. 교전은 아프가니스탄-파키스탄 국경을 따라 여러 지역에서 발생했으며, 북와지리스탄, 남와지리스탄, 와나, 데라이스마일칸, 샹글라, 호스트, 팍티카 등이 포함된다. 이후 발루치스탄 해방군에 의해 발루치스탄 주의 투르바트와 과다르에서도 공격이 감행되었다. 중국-파키스탄 경제 회랑(CPEC)과 미국 항공기가 주둔하는 파키스탄 군사 기지에 대한 무장 세력의 공격은 파키스탄 내 중국과 미국의 이해관계에 위협이 되고 있다. 2024년 3월 긴장 완화 후, 2024년 12월 팍티카주에 대한 파키스탄의 공습으로 분쟁이 다시 격화되었다.
12월의 충돌은 파키스탄이 아프가니스탄 영토에 대한 공습을 2년도 채 되지 않는 기간 동안 세 번째로 감행한 것을 의미한다. 첫 번째 유사한 아프간 영토에 대한 파키스탄 공습은 2022년에 발생했고, 두 번째 파키스탄 공습은 2024년 3월에 발생했다. 아프간 영토에 대한 파키스탄 공습의 세 번째이자 최신 공습은 2024년 12월에 있었다.
테흐리크-에-탈리반 파키스탄 또는 파키스탄 탈레반은 2007년에 파키스탄 내 다양한 강경 수니파 이슬람주의 세력의 연합으로 설립된 무장 단체이다. 이 단체는 파키스탄 북서부 지역인 연방 직할 부족 지역 에서 알카에다 관련 테러리스트들에 대한 군사 작전에 대한 대응으로 결성되었다.
처음에는 바이툴라 메수드가 이끌었던 이 단체는 주로 아프가니스탄 국경을 따라 위치하며, 약 30,000명에서 35,000명 사이의 회원이 있는 것으로 추정된다. 파키스탄 탈레반는 파키스탄의 선출된 정부를 전복하고 이슬람 율법에 따라 통치되는 에미르국을 건설하는 것을 목표로 한다. 이 목표를 달성하기 위해 파키스탄 탈레반는 파키스탄군을 공격하고 정치인들을 암살했다. 수많은 자살 폭탄 공격을 포함한 그들의 폭력적인 행동은 수백 명의 군인, 경찰관, 민간인의 사망을 초래했다.
파키스탄 탈레반는 파키스탄에서 교회, 학교, 그리고 탈레반의 여성 교육 제한에 반대하다가 2012년 암살 시도에서 살아남은 말랄라 유사프자이와 같은 저명한 인물을 표적으로 삼아 가장 파괴적인 공격을 감행했다.
2021년 탈레반이 아프가니스탄을 장악한 이후, 파키스탄 탈레반는 지도자와 전투원들이 아프가니스탄에 기반을 두고 있기 때문에 더욱 공격적으로 변모했다. 2022년 말 파키스탄 정부와의 휴전을 종식시킨 후, 파키스탄 탈레반는 공격을 강화하여 파키스탄 군인과 경찰에 사상자를 발생시켰다.
파키스탄은 과거 아프가니스탄 탈레반을 지원했다는 비난을 받았지만, 2021년 탈레반이 다시 집권한 이후 아프가니스탄과 파키스탄 간의 국경 분쟁이 반복적으로 발생했다. 파키스탄 정부는 아프가니스탄 탈레반 당국이 증가하는 반란 속에서 파키스탄 탈레반 반군을 숨겨주고 있다고 비난한다.
2024년 3월 16일, 무장 세력이 트럭 폭탄을 터뜨리고 국경 검문소에서 파키스탄 군인들에게 발포했다. 트럭 폭탄 공격으로 파키스탄 군인 5명이 사망했고, 추가 총격으로 2명이 더 사망했다. 파키스탄 육군에 따르면, 공격자들은 아프가니스탄을 공격 기지로 사용했으며, 6명의 공격자도 사망했다. 자이시-에-푸르산-에-무함마드라는 무장 단체가 이 공격의 책임을 주장했으며, 파키스탄 관리들은 이 단체의 구성원들이 파키스탄 탈레반의 일부라고 믿는다. 탈레반이 이끄는 아프가니스탄은 가해자들이 자국 영토에서 온 것이 아니라고 부인했다. 2024년 3월 17일, 파키스탄 대통령 아시프 알리 자르다리는 공격 가해자들에 대해 강력한 보복을 다짐했다.
파키스탄 공군 공습.
2024년 3월 18일, 아프가니스탄의 공격에 대응하여 파키스탄 공군은 아프가니스탄 동부 국경 지역인 호스트와 팍티카에 대해 두 차례 정보 기반 공습을 감행했다. 아프가니스탄 정부는 파키스탄이 여성 5명과 어린이 3명을 살해했다고 주장했다. 파키스탄은 이를 부인하며, 파키스탄 탈레반의 분파인 하피즈 굴 바하두르 무장 단체를 겨냥하여 테러리스트를 사살했으며, 고가치 표적인 지휘관 세라(Sehra) 또는 자난(Janan)을 성공적으로 사살했다고 주장했다. 또 다른 지휘관 압둘라 메수드(Abdullah Mehsud)도 사망했다고 주장했지만, 그는 나중에 비디오를 통해 주장을 반박했다. 메수드의 집이 표적이 되어 그의 아내와 어린 아들이 사망했다고도 보도되었다. 파키스탄은 파키스탄 탈레반과 그 분파 무장 조직이 수백 명의 파키스탄 민간인 사망의 원인이라고 비난하며, 이들이 아프가니스탄을 기지로 삼고 탈레반 내부의 지원을 받았다고 주장했다.