FHS에 대한 대안은 무엇입니까?

저는 15 년 넘게 오랫동안 Linux 사용자 였지만 열정으로 미워하는 것은 위임 된 디렉토리 구조입니다. 그 같은 난 몰라 /usr/bin에서 바이너리 또는 libs가에 대한 덤핑 땅이다 /usr/lib, /usr/lib32, /usr/libx32, /lib, /lib32등 ...에서 임의의 물건 /usr/share등이 바보와 혼란입니다. 그러나 일부는 좋아하고 맛이 다릅니다.

각 패키지가 격리 된 디렉토리 구조를 원합니다. 미디어 플레이어 드래곤이 자체 구조를 가지고 있다고 상상해보십시오.

/software/dragon
/software/dragon/bin/x86/dragon
/software/dragon/doc/README
/software/dragon/doc/copyright
/software/dragon/lib/x86/libdragon.so

또는:

/software/zlib/include/zlib.h
/software/zlib/lib/1.2.8/x86/libz.so
/software/zlib/lib/1.2.8/x64/libz.so
/software/zlib/doc/examples/...
/software/zlib/man/...

당신은 요점을 얻습니다. 내 옵션은 무엇입니까? 내 계획과 같은 것을 사용하는 Linux 배포판이 있습니까? 원하는 배포판 (Gentoo ??)처럼 작동하도록 일부 배포판을 수정할 수 있습니까? 아니면 LFS가 필요합니까? 이 분야에 선행 기술이 있습니까? 그 계획이 실현 가능하거나 실현 불가능한 지에 관한 출판물처럼?

OS X를 찾지 못했습니다. :) 그러나 OS X에서 영감을 얻은 것은 완전히 괜찮습니다.

편집 : 나는 아무 생각하는 방법이 없다 PATH, LD_LIBRARY_PATH그리고 해결해야 경로의 작은 집합에 따라 다른 환경 변수를. KDE 편집기 Kate가 설치되어 있으면 /software/kate/bin/x86/bin/kate바이너리의 전체 경로를 입력하여 시작할 수 있다고 생각합니다. 동적 라이브러리 및 dlopen호출에서 작동하는 방법을 모르겠지만 해결할 수없는 엔지니어링 문제는 아닙니다.

첫째, 선행 이해 상충 면책 조항 : 저는 오랜 GoboLinux 개발자입니다.

둘째, 도메인 전문 지식의 선구자 : 저는 오랜 GoboLinux 개발자입니다.

현재 사용중인 구조는 몇 가지가 있습니다. 고보 리눅스 에는 하나가 있으며 GNU Stow , Homebrew 등과 같은 도구는 주로 사용자 프로그램에서 매우 비슷한 것을 사용합니다. NixOS 는 또한 프로그램과 삶의 철학에 비표준 계층을 사용합니다. 또한 합리적으로 일반적인 LFS 실험이기도합니다.

나는 그것들을 모두 설명하고 그것이 실제로 어떻게 작동하는지에 대한 경험으로부터 의견을 제시 할 것이다 ( "타당성"). 짧은 대답은 그렇습니다, 그것은 가능하지만 실제로 그것을 원해야한다는 것 입니다.

고보 리눅스

GoboLinux는 설명과 매우 유사한 구조를 가지고 있습니다. 소프트웨어는 아래에 설치됩니다 /Programs: /Programs/ZSH/5.0.8일반적인 bin/ lib/ ... 디렉토리 에 ZSH 5.0.8에 속하는 모든 파일이 들어 있습니다 . 시스템 도구는 /System/Links계층 구조에서 해당 파일에 대한 심볼릭 링크를 작성하여 /usr¹에 매핑 됩니다. PATH변수는 하나의 통합 된 실행 파일 디렉토리를 포함하고, LD_LIBRARY_PATH사용되지 않습니다. 여러 버전의 소프트웨어가 한 번에 공존 할 수 있지만 지정된 이름 ( bin/zsh)의 파일 하나만 한 번에 연결됩니다. 전체 경로를 통해 다른 사람에게 액세스 할 수 있습니다.

호환성 심볼릭 링크의 세트는 또한 존재 /bin및 /usr/bin등등 통합 된 실행 파일 디렉토리에 매핑합니다. 따라서 런타임시 소프트웨어를보다 쉽게 ​​사용할 수 있습니다. 커널 패치 인 GoboHide를 사용하면 이러한 호환성 심볼릭 링크를 파일 목록에서 숨길 수 있지만 여전히 통과 할 수 있습니다.

다른 대답 은 커널 코드를 수정할 필요 가 없다는 것입니다 . GoboHide는 완전히 외관상이며 커널은 일반적으로 사용자 공간 경로에 의존하지 않습니다 ². GoboLinux에는 맞춤형 초기화 시스템이 있지만이를 수행 할 필요는 없습니다.

태그 라인은 항상 "파일 시스템은 패키지 관리자"이지만 시스템에는 상당히 일반적인 패키지 관리 도구가 있습니다. 다음을 사용하여 모든 것을 할 수 있습니다 cp, rm그리고 ln하지만.

GoboLinux를 사용하려면 매우 환영합니다. 그러나 소규모 개발 팀이므로 이전에 아무도 사용하지 않으려는 경우 원하는 소프트웨어가 패키지화되지 않았 음을 알 수 있습니다. 좋은 소식은 시스템을위한 프로그램을 만드는 것이 일반적으로 상당히 쉽다는 것입니다 (표준 "레시피"는 약 3 줄입니다). 나쁜 소식은 때때로 불쾌하게 복잡하다는 것입니다. 아래에서 더 자세히 다루겠습니다.

간행물

몇 가지 "게시물"이 있습니다. 나는에서 발표했다 linux.conf.au 2010 년 비디오에서 사용할 수 있습니다 일반적으로 모든 것을 커버 모든 것을, 같은 시스템에 : OGV MP4 (또한 해당 지역의 리눅스 호주 미러); 나는 또한 내 노트 를 산문에 썼다 . "유명한 포함한 몇 가지 오래된 문서도 있습니다 내가 우둔하지 않다 온," GoboLinux 웹 사이트 일부 반대하고 문제를 해결합니다. 요즘 우리는 조금 덜 쿵호라고 생각하며 향후 릴리스가 /usr심볼릭 링크의 기본 위치로 채택 될 것으로 생각합니다 .

NixOS

NixOS는 설치된 각 프로그램을 아래의 자체 디렉토리에 넣습니다 /nix/store. 이러한 디렉토리의 이름은 다음과 같습니다 /nix/store/5rnfzla9kcx4mj5zdc7nlnv8na1najvg-firefox-3.5.4/. 모든 프로그램의 종속성과 구성을 나타내는 암호화 해시가 있습니다. 해당 디렉토리 안에는 모든 관련 파일이 있으며, 그보다 더 많거나 적은 일반 위치가 로컬에 있습니다.

또한 한 번에 여러 버전을 가지고 있고 그중 하나를 사용할 수 있습니다. NixOS는 재현 가능한 구성과 관련된 전체 철학을 가지고 있습니다. 본질적으로 구성 관리 시스템이 처음부터 시작되었습니다. 설치 프로그램의 올바른 세계를 사용자에게 제시하기 위해 환경 조작에 의존합니다.

LFS

Linux From Scratch 를 사용하는 것은 매우 간단합니다. 원하는 계층 구조를 설정하는 것은 합니다. 디렉토리를 만들고 모든 것을 올바른 위치에 설치하도록 구성하십시오. GoboLinux 실험을 빌드하는 데 몇 번이나 해왔으며 일반 LFS보다 어렵지 않습니다. 이 경우 호환성 심볼릭 링크를 만들어야합니다. 그렇지 않으면 상당히 어렵지만, 유니온 마운트를주의해서 사용하면 실제로 원한다면이를 피할 수 있습니다.

한 시점에서 정확히 LFS 힌트 가있는 것처럼 느껴지 지만 지금은 찾을 수없는 것 같습니다.

타당성

FHS의 표준은 표준이며 매우 일반적이며 작성 당시의 기존 사용량을 광범위하게 반영한다는 것입니다. 대부분의 사용자는 본질적으로 해당 레이아웃을 따르지 않는 시스템을 사용하지 않습니다. 그 결과 많은 소프트웨어가 아무도 모르는 사이에 잠재적 인 의존성을 가지고 있으며, 종종 의도하지 않게 완전히 실현하지 못합니다.

모든 스크립트는 #!/bin/bash? Bash가 없으면 좋지 않습니다. 이것이 GoboLinux가 모든 호환성 심볼릭 링크를 갖는 이유입니다. 그것은 실용적입니다. 많은 소프트웨어가 빌드 타임이나 비표준 레이아웃에서 런타임에 작동하지 못하며, 수정하기 위해서는 패치가 필요합니다.

기본 Autoconf 프로그램은 일반적으로 사용자가 말한 곳마다 행복하게 설치되며 올바로 전달하는 프로세스를 자동화하는 것은 매우 쉽습니다 --prefix. 다른 빌드 시스템은 의도적으로 계층 구조에서 베이킹하거나 주요 작성자가 이식 불가능한 구성을 작성하여 항상 그렇게 좋은 것은 아닙니다. CMake는 후자의 주요 범죄자입니다. 즉,이 세상에 살고 싶다면 다른 사람들의 빌드 시스템에서 많은 노력을 기울일 준비가되어 있어야합니다. 컴파일하는 동안 생성 된 파일을 동적으로 패치해야하는 것은 매우 번거 롭습니다.

런타임은 또 다른 문제입니다. 많은 프로그램은 자신의 파일 또는 다른 사람의 파일이 상대적으로 또는 절대적으로 발견되는 위치에 대한 가정을 가지고 있습니다. 심볼릭 링크를 사용하여 일관된 견해를 나타 내기 시작하면 많은 프로그램에서 버그를 처리하는 버그가 있습니다 (또는 때로는 도움이되지 않는 올바른 행동). 예를 들어, 도구 foobar는 도구 baz옆에서 또는에서 실행 파일 을 찾을 것으로 예상 할 수 ../sbin있습니다. 심볼릭 링크를 읽는지 여부에 따라 두 위치가 서로 다르며 둘 중 어느 것도 맞지 않을 수 있습니다.

결합 된 문제는 /usr/share디렉토리입니다. 물론 공유 파일 용이지만 모든 프로그램을 자체 접두사에 넣으면 더 이상 실제로 공유되지 않습니다. 이로 인해 프로그램이 표준 아이콘 등을 찾을 수 없습니다. GoboLinux는 이것을 아주 추악한 방식으로 처리했습니다. 빌드 타임에는 $prefix/share에 대한 심볼릭 링크였으며 링크를 만든 $prefix/Shared후 share대신 글로벌 디렉토리를 가리 켰습니다 . 이제 컴파일 타임 샌드 박싱 및 파일 이동을 사용하여 share(및 다른 디렉토리)를 처리하지만 링크 읽기로 인한 런타임 오류는 여전히 문제가 될 수 있습니다.

여러 프로그램 모음은 또 다른 문제입니다. GoboLinux는 그놈이 완전히 작동하는 것을 결코 얻지 못했으며, NixOS도 믿지 않습니다. 레이아웃 상호 의존성이 너무 높아서 모두 치료할 수 없기 때문입니다.

따라서 가능합니다 .

• 기능을 수행하는 데는 많은 작업이 필요합니다.
• 일부 소프트웨어는 작동하지 않을 수 있습니다.
• 사람들은 당신을 재밌게 볼 것입니다.

그것들은 모두 당신에게 문제가 될 수도 있고 아닐 수도 있습니다.

¹ 버전 14.01은를 사용하여 /System/Index직접 매핑됩니다 /usr. 향후 버전에서 링크 / 인덱스 계층 구조가 삭제되고 전체적으로 사용될 수 있다고 생각합니다 /usr.

² /bin/sh기본적으로 존재 해야 합니다.

두 GoboLinux (F.sb 언급)과 guix GNU 바이너리의 "현재"버전으로 지점으로 심볼릭 링크와 함께 당 패키지 디렉토리 구조를 사용하는 배포판입니다.

안정적인 시스템을 원한다면 GoboLinux가 더 나은 방법으로 보입니다. GNU guix는 아직 프로덕션 준비가되지 않았다고 명시 적으로 밝혔다. GoboLinux는 수년 동안 사용되었습니다. 나는 나 자신을 시도한 적이 없다.

GoboLinux를 확인하십시오 .

디렉토리 구조를 변경하려면 일부 커널 코드, 부트 프로세스, rc 파일을 기반으로하는 디렉토리 런레벨 및 패키지 관리자를 변경 한 다음 디렉토리 구조를 변경해야합니다.

Linux FHS는 1980 년대 후반 Sun 및 기타 UNIX 회사가 결정한 내용을 기반으로합니다.

그 시간에 중요한 변화는 포기했다 /usr/local/및 소개 /opt/{/ bin! lib! man! ...}

오늘 / usr / bin이 덤프 장으로 사용되는 이유를 찾고 있다면 그놈이 가장 책임감있는 프로젝트 중 하나라고 생각합니다.

32 비트 대 64 비트 라이브러리에서 발생한 것은 FHS에 의한 것으로 보입니다.

Solaris는 /lib /usr/bin및에 플랫폼 별 하위 디렉토리를 도입했습니다 /usr/lib. Sun이 1988 년부터 기본 개념을 개선 한 방법을 원합니다.

모든 패키지는 파일 시스템의 고유 한 부분이 있다면, 당신은 매우 크고 다루기 힘든 환경 변수 필요할 것 PATH, LD_LIBRARY_PATH그리고 유사한.

물론 이런 식으로 패키지를 직접 설치 한 다음 GNU 모듈과 같은 것을 사용하여 환경에 있는지 여부를 관리 할 수 ​​있습니다. 이것이 우리가 일하는 과학 소프트웨어를 위해 우리가하는 일이지만 우리는 그렇게하지 않습니다. 시스템 소프트웨어.