Unix의 철학

Unix philosophy
Unix 철학의 주요 지지자인 Ken Thompson과 Dennis Ritchie

Ken Thompson이 창안한 Unix 철학은 최소한의 모듈러 소프트웨어 개발에 대한 문화적 규범과 철학적 접근법입니다.Unix 운영 체제의 주요 개발자들의 경험을 바탕으로 합니다.초기 Unix 개발자들은 모듈화와 재사용성의 개념을 소프트웨어 엔지니어링 업무에 도입하는 데 중요했고, "소프트웨어 도구" 운동을 일으켰다.시간이 지남에 따라 Unix(및 Unix에서 실행되는 프로그램)의 주요 개발자들은 소프트웨어 개발을 위한 문화적 규범을 확립했습니다. 이러한 규범은 Unix 자체의 기술만큼이나 중요하고 영향력이 커졌으며 "Unix 철학"으로 불리게 되었습니다.

Unix의 철학은 단순하고 콤팩트하며 명확하며 모듈러형이며 확장 가능한 코드를 만드는 것을 강조합니다.이 코드는 개발자가 아닌 개발자가 쉽게 유지 보수 및 용도 변경할 수 있습니다.Unix의 철학은 획일적인 디자인이 아닌 컴포지터빌리티를 선호합니다.

기원.

UNIX의 이념은 1978년부터 [2]Bell System Technical Journal에 Doug McIlroy가[1] 문서화하고 있습니다.

  1. 각 프로그램이 한 가지 일을 잘하도록 하세요.새로운 작업을 수행하려면 새로운 "기능"을 추가하여 오래된 프로그램을 복잡하게 만들지 말고 새로 구축하십시오.
  2. 모든 프로그램의 출력이 아직 알려지지 않은 다른 프로그램에 대한 입력이 될 것으로 예상합니다.출력에 관계없는 정보를 흐트러뜨리지 마십시오.문자열 형식의 컬럼 또는 바이너리 입력 형식을 사용하지 마십시오.인터랙티브 입력을 고집하지 마십시오.
  3. 소프트웨어, 심지어 운영체제를 조기에, 이상적으로는 몇 주 이내에 시험할 수 있도록 설계 및서투른 부분은 주저하지 말고 버리고 다시 만들어라.
  4. 툴을 구축하기 위해 우회해야 하는 경우에도 툴을 사용하여 프로그래밍 작업을 가볍게 할 수 있습니다.사용이 끝나면 툴 중 일부를 폐기할 수 있습니다.

나중에 Peter H. Salus가 Unix의 4분의 1세기(1994)[1]에 정리했다.

  • 한 가지 일을 잘 하는 프로그램을 작성하세요.
  • 함께 작업할 프로그램을 작성합니다.
  • 텍스트 스트림을 처리하는 프로그램을 작성합니다.그것은 범용 인터페이스이기 때문입니다.

Ritchie와 Thompson은 1974년 수상 경력이[3] 있는 Unix 문서에서 다음과 같은 설계상의 [4]고려사항을 인용했습니다.

  • 프로그램의 기입, 테스트, 실행을 용이하게 합니다.
  • 배치 처리 대신 대화형 사용.
  • 크기 제약으로 인한 디자인('고통을 통한 절약')의 경제성 및 우아함.
  • 셀프 지원 시스템: 모든 Unix 소프트웨어는 Unix에서 관리됩니다.

UNIX 프로그래밍 환경

Bell Labs의 The UNIX Programming Environment, Brian Kernighan 및 Rob Pike는 1984년 서문에서 UNIX 설계와 [5]UNIX 철학에 대해 간략히 설명합니다.

UNIX Programming Environment 공동저자인 Rob Pike 씨

UNIX 시스템이 많은 혁신적인 프로그램과 기술을 도입하고 있지만, 어떤 단일 프로그램이나 아이디어도 이를 잘 작동시키지 않습니다.대신, 이것을 효과적으로 만드는 것은 컴퓨터 사용의 철학인 프로그래밍에 대한 접근법이다.그 철학을 한 문장으로 적을 수는 없지만, 그 중심에는 프로그램 자체보다는 프로그램 간의 관계에서 더 많은 시스템의 힘이 나온다는 생각이 있습니다.많은 UNIX 프로그램이 고립되어 매우 사소한 작업을 하지만 다른 프로그램과 결합하면 일반적이고 유용한 도구가 됩니다.

저자들은 또한 이 책의 목표가 "유닉스 프로그래밍 [5]철학을 전달하는 것"이라고 쓰고 있다.

UNIX 환경에서의 프로그램 설계

Brian Kernighan은 Unix 철학을 상세하게 썼다.

1984년 10월 Brian Kernighan과 Rob Pike는 UNIX 환경의 프로그램 설계라는 논문을 발표했습니다.이 문서에서는 4.2와 같은 일부 새로운 Unix 시스템에서 볼 수 있는 프로그램 옵션과 기능의 추가를 비판합니다.BSD와 System V는 소프트웨어 툴의 Unix 철학을 설명하고, 각각 하나의 일반적인 [6]기능을 수행합니다.

UNIX operating system의 파워의 대부분은, 프로그램을 사용하기 쉽고, 보다 중요한 것은, 다른 프로그램과의 결합을 용이하게 하는 프로그램 설계 스타일입니다.이 스타일은소프트웨어도구사용이라고 불리며프로그램환경에적합하는방법및내부설계방법에따라다른프로그램과사용하는방법에따라달라집니다.[...] 이 스타일은 도구를 사용한 것입니다.프로그램을 개별적으로 사용하거나 작업을 수행하기 위해 조합하여 사용하는 것이 아니라 프로그램을 사용하는 것입니다.단일 자급자족 서브시스템 또는 특수 목적의 일회성 프로그램에 의한 수동 작업입니다.

작성자는 다음과 같은 Unix 툴과 대조됩니다.다른 [6]시스템에서 사용하는 더 큰 프로그램 스위트와 함께 사용할 수 있습니다.

cat의 디자인은 대부분의 UNIX 프로그램의 전형적인 형태입니다.이것은 많은 다른 애플리케이션(원작자가 상상하지 못한 많은 것을 포함)에서 사용할 수 있는 단순하지만 일반적인 기능을 구현합니다.다른 명령어는 다른 기능에 사용됩니다.예를 들어 파일 이름 변경, 파일 삭제 또는 파일 크기 확인과 같은 파일 시스템 작업에 대한 별도의 명령이 있습니다.다른 시스템은 이를 내부 구조와 명령어를 가진 단일 "파일 시스템" 명령어로 묶습니다.(CP/M이나 RSX-11 등의 운영체제에서 볼 수 있는 PIP 파일 복사 프로그램이 그 예입니다.)이러한 접근법이 반드시 더 나쁘거나 더 나은 것은 아니지만 UNIX 철학에 반하는 것은 분명합니다.

UNIX 프로그래밍에 관한 Doug McIlroy씨

더그 매킬로이(왼쪽)와 데니스 리치

당시 Bell Labs Computing Sciences Research Center 책임자이자 Unix 파이프의 [7]발명자인 McIlroy는 Unix의 철학을 다음과 [1]같이 요약했습니다.

이것이 Unix의 철학입니다.한 가지 일을 잘 하는 프로그램을 작성합니다.함께 작업할 프로그램을 작성합니다.텍스트 스트림을 처리하는 프로그램을 작성합니다.그것은 범용 인터페이스이기 때문입니다.

그는 또한 유닉스 프로그래밍의 [1]단순성과 미니멀리즘을 강조했습니다.

"친밀하고 아름다운 복잡성"이라는 개념은 거의 모순이다.Unix 프로그래머들은 '심플하고 아름다운' 영예를 두고 서로 경쟁합니다.이 점은 이러한 규칙에 내포되어 있지만 분명히 밝힐 가치가 있습니다.

반대로, McIlroy는 현대 리눅스가 소프트웨어가 부풀어 오른다고 비판하면서, "팬들이 Linux의 좋은 점을 실망시키는 [8]비만 상태로 만들었다"고 말했다.그는 이것을 Research [9]Unix를 개발 및 개정할 때 Bell Labs에서 취했던 이전 접근법과 비교합니다.

모든 것이 작았다...사이즈를 보면 Linux에 마음이 놓입니다.[...] 매뉴얼 페이지는 예전에는 매뉴얼 페이지였지만 지금은 수천 개의 옵션을 갖춘 작은 볼륨입니다.우리는 UNIX Room에 앉아서 '우리가 무엇을 버릴 수 있을까?왜 이런 선택지가 있는 거죠?기본 설계에 약간의 결함이 있기 때문입니다.설계의 요점을 제대로 파악하지 못했습니다.옵션을 추가하는 대신 무엇이 해당 옵션을 추가하도록 강요했는지 생각해 보십시오.

한 가지 일을 잘 해내세요

McIlroy가 언급했듯이 Unix 커뮤니티 전체에서 일반적으로 받아들여지고 있는 Unix 프로그램은 항상 DOTADIW(Do One Thing And Do It Well)의 개념을 따를 것으로 기대되어 왔습니다.인터넷에서는 DOTADIW라는 약어의 출처는 한정되어 있지만, 특히 Linux 커뮤니티에서 새로운 운영체제를 개발하고 패키징할 때 상세하게 논의됩니다.

Slackware Linux의 프로젝트 리더인 Patrick Volkerding은 systemd 아키텍처에 대한 비판에서 이 설계 원칙을 언급하며 "서비스, 소켓, 디바이스, 마운트 등을 제어하려고 하면 하나의 데몬 내에서 모든 것이 하나의 일을 하고 그것을 [10]잘한다는 Unix의 개념에 어긋난다"고 말했다.

Eric Raymond의 17가지 Unix 규칙

2003년에 [11]처음 출판된 그의 책 The Art of Unix Programming에서 Eric S. Raymond(오픈 소스 옹호자이자 프로그래머)는 Unix 철학을 KISS 원칙인 "Keep it Simple, Studp"[12]으로 요약합니다.그는 다음과 같은 [1]일련의 설계 규칙을 제공합니다.

  • 모듈러 프로그램 구축
  • 읽을 수 있는 프로그램 쓰기
  • 구성 사용
  • 메커니즘과 정책 분리
  • 간단한 프로그램 작성
  • 소규모 프로그램 작성
  • 투명 프로그램 쓰기
  • 견고한 프로그램 작성
  • 프로그램이 아니라 필요할 때 데이터를 복잡하게 만듭니다.
  • 잠재 사용자의 예상 지식을 기반으로 구축
  • 불필요한 출력 방지
  • 진단이 용이한 방법으로 실패한 프로그램을 작성합니다.
  • 머신 타임에 걸친 개발자 시간
  • 손으로 코드를 쓰는 대신 코드를 생성하는 추상 프로그램을 작성합니다.
  • 광내기 전 시제품 소프트웨어
  • 유연하고 개방적인 프로그램
  • 프로그램 및 프로토콜을 확장할 수 있도록 합니다.

Mike Gancarz:UNIX의 철학

1994년, Mike Gancarz(X Window 시스템을 설계한 팀의 일원)는 Unix와의 경험을 바탕으로 Unix에 의존하는 동료 프로그래머 및 다른 분야의 사람들과 논의하여 Unix 철학을 9개의 가장 중요한 교훈으로 요약했습니다.

  1. 작은 것은 아름답다.
  2. 각 프로그램이 한 가지 일을 잘하도록 하세요.
  3. 가능한 한 빨리 시제품을 만들어라.
  4. 효율보다 휴대성을 선택합니다.
  5. 데이터를 플랫 텍스트 파일에 저장합니다.
  6. 소프트웨어를 활용하여 고객에게 유리하게 활용하십시오.
  7. 셸 스크립트를 사용하여 활용도와 휴대성을 높입니다.
  8. 캡티브 사용자 인터페이스를 피합니다.
  9. 모든 프로그램을 필터로 만듭니다.

'악화가 낫다'

주요 기사:나쁜 것은 좋은 것이다

Richard P. Gabriel은 Unix의 주요 장점은 Unix가 "최악"이라는 설계 철학을 구현했다는 것입니다. 즉, 인터페이스와 구현의 단순성이 정확성, 일관성 및 완전성을 포함하여 시스템의 다른 특성보다 더 중요하다는 것입니다.가브리엘은 일부 결과의 품질에 의문을 제기하지만 이러한 디자인 스타일은 진화의 주요 이점을 가지고 있다고 주장한다.

예를 들어 초기 UNIX는 모노리식 커널(사용자 프로세스가 사용자 스택 상에서 모두 커널 시스템 호출을 수행했음을 의미합니다)을 사용했습니다.커널의 장기 I/O에서 차단된 상태에서 프로세스에 신호가 전달된 경우 어떻게 해야 합니까?I/O가 완료되는 동안 신호가 장시간(아마도 무기한) 지연되어야 합니까?프로세스가 커널 모드이고 스택에 중요한 커널 데이터가 있는 경우 신호 핸들러를 실행할 수 없습니다.신호 핸들러가 정상적으로 완료되었을 경우 커널은 시스템콜을 백아웃하여 저장해야 합니까?또, 나중에 재생 및 재기동할 수 있습니다.

이러한 경우 켄 톰슨과 데니스 리치는 완벽함보다 단순함을 선호했다.UNIX 시스템이 시스템콜에서 조기에 돌아와 아무것도 하지 않았다는 에러(「Interrupted System Call」또는 에러 번호 4)가 표시되는 일이 있습니다.EINTR)를 도입하고 있습니다.물론 신호 핸들러를 호출하기 위해 콜이 중단되었습니다.이 문제가 발생할 수 있는 것은 다음과 같은 장기 실행 중인 소수의 시스템콜뿐이에요read(),write(),open(),그리고.select()이로 인해 I/O 시스템의 설계와 이해가 몇 배 더 간단해졌습니다.대부분의 사용자 프로그램은 다음 이외의 신호를 처리하거나 경험하지 않았기 때문에 영향을 받지 않았습니다.SIGINT한 마리만 키우면 바로 죽을 거예요.작업 제어 키 누름에 응답하는 셸이나 텍스트에디터 등의 일부 다른 프로그램에서는 시스템콜에 작은 래퍼를 추가하여 콜을 즉시 재시도할 수 있습니다.EINTR에러가 발생했습니다.따라서, 그 문제는 간단한 방법으로 해결되었다.

비판

1981년 "유닉스의 진실:Datamation에 게재된 "사용자 인터페이스는 끔찍하다"[13]고 Don Norman은 유닉스의 디자인 철학이 사용자 인터페이스에 대한 관심이 없다고 비판했다.인지 과학에서 그의 배경과 인지 engineering,[14]의 그는 최종 사용자 comprehend에 그리고 그 결과 처참한 실수 함께(그런 일을 한시간의 가치를 잃어버린 것으로)과 systems—or의 Unix의 케이스 안에 개인용 인지 모델을 이해하는 데 실패하고 있는데 중점을 둔 세력 그 철학의 관점에서 쓴다.e는너무 쉬워요.

「 」를 참조해 주세요.

메모들

  1. ^ a b c d e Raymond, Eric S. (2004). "Basics of the Unix Philosophy". The Art of Unix Programming. Addison-Wesley Professional (published 2003-09-23). ISBN 0-13-142901-9. Retrieved 2016-11-01.
  2. ^ Doug McIlroy, E. N. Pinson, B. A. Tague (8 July 1978). "Unix Time-Sharing System: Foreword". The Bell System Technical Journal. Bell Laboratories: 1902–1903.{{cite journal}}: CS1 maint: 여러 이름: 작성자 목록(링크)
  3. ^ "ACM - Dennis M. Richie". Archived from the original on January 26, 2021. Retrieved August 26, 2021. ACM Programming Systems and Languages Paper Award
  4. ^ Dennis Ritchie; Ken Thompson (1974), "The UNIX time-sharing system" (PDF), Communications of the ACM, 17 (7): 365–375, doi:10.1145/361011.361061, S2CID 53235982
  5. ^ a b 커니건, 브라이언 W. 파이크, 롭UNIX Programming Environment, 1984년8
  6. ^ a b Rob Pike; Brian W. Kernighan (October 1984). "Program Design in the UNIX Environment" (PDF).
  7. ^ Dennis Ritchie (1984), "The Evolution of the UNIX Time-Sharing System" (PDF), AT&T Bell Laboratories Technical Journal, 63 (8): 1577–1593, doi:10.1002/j.1538-7305.1984.tb00054.x
  8. ^ Douglas McIlroy. "Remarks for Japan Prize award ceremony for Dennis Ritchie, May 19, 2011, Murray Hill, NJ" (PDF). Retrieved 2014-06-19.
  9. ^ Bill McGonigle. "Ancestry of Linux — How the Fun Began (2005)". Retrieved 2014-06-19.
  10. ^ "Interview with Patrick Volkerding of Slackware". linuxquestions.org. 2012-06-07. Retrieved 2015-10-24.
  11. ^ Raymond, Eric (2003-09-19). The Art of Unix Programming. Addison-Wesley. ISBN 0-13-142901-9. Retrieved 2009-02-09.
  12. ^ Raymond, Eric (2003-09-19). "The Unix Philosophy in One Lesson". The Art of Unix Programming. Addison-Wesley. ISBN 0-13-142901-9. Retrieved 2009-02-09.
  13. ^ Norman, Don (1981). "The truth about Unix: The user interface is horrid" (PDF). Datamation. Vol. 27, no. 12.
  14. ^ "An Oral History of Unix". Princeton University History of Science.

레퍼런스

외부 링크