Linux (예 : Debian / Gnu Linux)에 응용 프로그램을 설치하면 응용 프로그램의 파일이 파일 시스템의 여러 디렉토리에 복사됩니다.
일부 스크립트는 / usr / share .. / usr / local로 이동 하고 다른 파일은 / var .. / log .. etc /로 이동 합니다.
나에게 이것은 파일 시스템에 대해 뭔가를 배웠기 때문에 괜찮습니다. 대부분의 디렉토리는 특정 목적을 위해 파일을 보유하기 위해 있습니다. 이것은 유닉스 철학에 아주 잘 맞습니다. "한 가지 일을 잘해라"
그러나 내 질문은 그러한 디렉토리 구조의 장점 은 무엇입니까? 아니면 단순히 유닉스 시대의 유산일까요? (예 : 응용 프로그램의 모든 파일이 하나의 특정 "폴더"에있는 하나의 창 사용과 비교)
답변:
가장 생각하기 쉬운 장점은 비슷한 파일이 동일한 디렉토리 트리에 있다는 것입니다. 구성 파일은 /etc로그 파일 및 / 또는 런타임 추적 파일에 /var/log있고 실행 /usr/bin파일은 PID 파일과 같은 런타임 정보에 /var/run있습니다. NTP 구성 파일에 무엇이 있는지 알고 싶습니까? 디렉토리를 변경 /etc하고 할 ls ntp*. 일부 전통적인 파일 시스템 바이러스가 감염되지 않도록 일부 프로그램이 실행 파일을 감시하도록 하시겠습니까? 의 모든 /usr/bin및 /usr/local/bin요구 사항보고.
제가 생각할 수있는 두 번째 장점은 Unix 스타일의 조직이 데이터와 실행 파일의 분리를 촉진한다는 것입니다. 실행 파일은 템플릿이있는 곳 ( /usr/share아마도)과 데이터가있는 곳이 아닌 디렉토리에 있습니다. 이러한 분리는 Unix / Linux / * BSD가 Windows보다 파일 시스템 바이러스에 대한 저항력이 높거나 이전 Pre-OSX Mac보다 높은 이유 일 수 있습니다.
/bin, /etc에서 /.
어떤 조직을 선택하더라도 어떤 것이 더 쉽고 어려워집니다.
유형, 유닉스 방식으로 파일을 정리 (에 bin, man, lib/python, ...), 쉽게 파일을 사용할 수 있습니다. 명령을 실행하려면 어떤 패키지를 제공하든 명령을 찾을 위치를 알고 있어야합니다. 문서를 검색하려면 모두 한곳에 있습니다. 일부 프로그램이 Vim 구문 강조 모듈, zsh 완성 함수 또는 Python 바인딩을 제공하는 경우 관련 파일은 vim / zsh / python에서 찾을 수있는 위치에 있습니다.
유닉스는 또한 사용 패턴에 따라 파일을 구성합니다. 구성 파일이 들어가고 /etc, 정상 작동 중에 변경되지 않는 /usr파일이 들어오고, 자동으로 변경된 파일이 들어갑니다 /var. 사용자 데이터는 아래에 /home있습니다. 이것은 구성 관리 ( /etc설치된 패키지 목록 에 포함 된 내용 관리)에 매우 유용합니다 . 그것은 백업 전략을 정의하는 것도 유용하다 :에 무엇이 /etc와 /home매우 중요하다, 반면에 무엇이 /usr쉽게 다시 다운로드 할 수 있습니다.
유닉스 방식의 주요 비용은 소프트웨어 설치가 여러 디렉토리에 분산되어 있다는 것입니다. 그러나 현대 유닉스 시스템에는 어쨌든 패키지 관리자가 있습니다. 많은 디렉토리에서 파일을 관리하는 것은 그다지 복잡하지 않습니다 (종속성을 추적하는 것은 매우 유용하고 어렵습니다).
Windows와는 대조적입니다. Windows는 패키지 관리없이 시작했으며 각 응용 프로그램은 자체 디렉토리를 생성했습니다. 프로그램, 정적 데이터, 사용자 데이터 등과 같은 모든 파일은 일반적으로 해당 디렉토리 안에 있습니다. 프로그램은 충돌을 고려하지 않고 공통 시스템 디렉토리에 놓이는 라이브러리를 제외하고 ( "DLL 지옥"). 시간이 지남에 따라 Windows는 다중 사용자가되어 시스템 디렉토리에서 사용자 디렉토리를 분리해야했습니다. Windows는 또한 구성 파일 (Unix 's /etc) 및 일부 시스템 데이터 (Unix ' s ) 의 중앙 위치를 만들었습니다./var), 레지스트리. 이는 패키지 관리 부족과 단일 사용자 시스템으로서의 초기 기록으로 인해 역사적으로 더 많은 유물입니다. Windows 접근 방식에는 많은 제한이 있습니다. 소프트웨어 패키지가 쉽게 상호 작용할 수 없습니다. 예를 들어, 대부분의 설치된 소프트웨어는 기본 명령 검색 경로로 끝나지 않으므로 모든 형태의 스크립팅과 제대로 상호 작용하지 않습니다. 설치 프로그램은 일반적으로 별도의 시스템 디렉토리 (la Unix!)에 드롭 된 메뉴 아이콘을 특수한 경우로 제공합니다.
유닉스 접근법의 한계는 패키지의 여러 버전의 공존을 쉽게 허용하지 않는다는 것인데, 이는 패키지가 업그레이드되는 동안 특히 문제가됩니다. 두 세계를 최대한 활용하는 방법은 각 패키지를 자체 디렉토리 ( /opt구조) 에 풀고 패키지 디렉토리에서 구조로 심볼릭 링크 포리스트를 만드는 것입니다 /usr. 이것은 stow 와 같은 소프트웨어가하는 일 입니다.
요약하면, Unix 방식은 파일을보다 쉽게 사용하고, 파일을 관리하고, 패키지가 상호 작용하도록합니다. 패키지 관리 소프트웨어가 필요하지만 어쨌든 바람직합니다. Windows 접근 방식을 사용하면 패키지를 수동으로 쉽게 관리 할 수 있지만 유용한 기능을 얻으려면 Unix 모델을 사용해야합니다.
위에서 언급하지 않은 주요 이점과 구조의 역사적 이유 중 하나는 부팅 프로세스의 여러 단계에서 사용 가능한 여러 볼륨 / 디스크의 물리적 분리입니다.
또 다른 이점은 다양한 디렉토리가 디렉토리의 데이터에 최적화 된 볼륨 / 파일 시스템에 마운트 될 수 있다는 것입니다. 예를 들어, tmpfs대 /run; 그리고 /sbin읽기 전용 미디어 / ROM.
또한 볼륨은 로컬 또는 원격, 개인 또는 공유 일 수 있습니다.
마지막으로 UNIX (OS X ), Linux ( ROX Desktop ) 및 Windows ( PortableApps.com ) 에서 사용되는 대체 방법 (@fluffy로 언급) 은 응용 프로그램 디렉토리 를 참조하십시오 ..app
이 레이아웃에는 응용 프로그램의 공유 및 구성 파일 위치를 쉽게 추측 할 수 있다는 점 외에는 실제로이 레이아웃에는 이점이 없습니다. 유닉스는 이런 종류의 레이아웃에 대한 오랜 유산을 가지고 있으며, 그것을 깨는 것은 꽤 어려울 것입니다. 그러나 일부 UNIX 배포판은 모델을 변경했습니다. 기존의 위치를 레거시 목적으로 만 제공하고 다른 앱은 자체 디렉토리 / 패키지에 번들로 제공됩니다. Mac OS X가 가장 눈에 띄는 예이며, 똑같은 일을하는 모호한 Linux 배포판이 있습니다 (Android는 비슷한 기능을 수행하고 조금 더 나아가서 자체 사용자 ID로 모든 응용 프로그램을 설치 및 시작합니다) ).
파일 시스템 규칙이 제공하는 주요 사항은 사람들이 파일을 찾을 위치 (수동 또는 코드)를 알 수 있도록하는 규칙입니다. 다른 방법으로 넘어야 할 진정한 기술적 이유는 없습니다.