Windows, 특히 이전 버전에서는 프로그램이 C:\Program Files디렉토리에 구성 파일과 일정하지 않은 데이터를 저장하는 것이 일반적이었습니다 . 이것은 프로그램이 일반적으로 단일 사용자, 네트워크가 아닌 파일 권한이없는 DOS에서 설치되고 실행되는 방식에서 파생됩니다.
보안 관점에서 이것은 나쁜 생각입니다. 실행 코드가있는 장소는 수정 가능한 데이터와 분리해야합니다. 이렇게하면 권한이없는 사용자가 설치된 바이너리를 수정하지 못하도록 적절한 파일 권한을 쉽게 적용 할 수 있습니다. 마찬가지로 주 실행 파일과 별도로 업데이트 될 수있는 라이브러리 디렉토리도 별도의 디렉토리에 있어야합니다.
Vista와 UAC 성가심의 출현으로이 전통은 마침내 견인력을 심각하게 잃기 시작했습니다.
훨씬 이전부터 다중 사용자 시스템 인 UNIX 및 Linux는 루트 이외의 사용자가 설치된 바이너리를 수정하지 못하도록해야했기 때문에 실행 디렉토리를 다른 디렉토리와 분리하는 경향이있었습니다. 또한 별도의 파티션 인 이유 /usr도 /sbin있습니다. 특히 보안에 민감한 관리자는 해당 파티션을 읽기 전용으로 마운트하고 설치 / 제거가 필요할 때 읽기 / 쓰기를 다시 마운트 할 수 있습니다.
패키지는 일반적으로 패키지 관리자에서 설치됩니다. aptitude(데비안 및 파생 배포판), yum(Redhat 및 파생 배포판), pacman(이 배포판을 잊어 버렸습니다 ...) 및 기타 와 같은 다양한 패키지 관리자 가 있습니다.
패키지 관리자를 사용하면 정교하고 무료 인 "앱 스토어"와 같이 리포지토리를 탐색하고 소프트웨어를 다운로드, 설치, 쿼리 및 제거 할 수 있습니다. 의존성을 관리하고 현재 설치된 것을 추적하는 책임을 맡습니다.
일반적으로 패키지 관리자는 리포지토리 외부에서 수동으로 다운로드 한 패키지에 대해 동일한 작업을 허용합니다. 직접 만들거나 컴파일 한 소프트웨어에서 직접 도구를 만들려는 경우에도 도구를 사용할 수 있습니다.
패키지 자체는 실행 파일이 아니기 때문에 신뢰할 수없는 실행 파일을 실행할 필요가 없습니다. (Windows가 마지막으로 배포하여 업데이트를 주변에 오는 것은 .msu'대신이야 .exe- 만의' .msi... 님은 한 동안 주위에 있었다)
rpm, 당신은 사용rpm -q --whatprovides후 특정 파일의 패키지 이름을 찾을 수 및rpm -q -a설치 패키지 파일을 어떻게 알아.