저는 15년 넘게 오랫동안 Linux를 사용해 왔습니다. 하지만 제가 정말 싫어하는 것 중 하나는 강제 디렉터리 구조입니다. 나는 그것이 , , , 등의 /usr/bin바이너리나 라이브러리에 대한 덤프 라는 것을 좋아하지 않습니다 /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 편집기가 있었다면케이트일단 설치되면 /software/kate/bin/x86/bin/kate바이너리의 전체 경로를 입력하여 실행할 수 있습니다. 동적 라이브러리 및 호출이 어떻게 작동하는지 모르겠지만 dlopen해결할 수 없는 엔지니어링 문제가 될 수는 없습니다.
답변1
첫째, 이해 상충 진술을 미리 명시해야 합니다. 저는 오랫동안 GoboLinux 개발자였습니다.
둘째, 도메인 전문 지식에 대한 사전 진술입니다. 저는 오랫동안 GoboLinux 개발자였습니다.
현재 다양한 구조가 사용되고 있습니다.고보리눅스하나 있고, 이런 도구도 있어요GNU 스토우,스스로 만든등, 매우 유사한 것을 사용합니다(주로 사용자 프로그램의 경우).닉 OS또한 프로그래밍 및 생활 철학에 비표준 계층 구조를 사용합니다. 이것은 또한 매우 일반적인 LFS 실험입니다.
나는 이 모든 것을 설명한 다음 그것이 실제로 얼마나 잘 작동하는지("타당성") 경험적으로 논평할 것입니다. 짧은 대답은예, 가능합니다. 하지만 정말로 원해야 합니다..
고보리눅스
GoboLinux의 구조는 당신이 설명하는 것과 매우 유사합니다. 소프트웨어는 다음 위치에 설치됩니다 /Programs. /Programs/ZSH/5.0.8일반적인 bin/ lib/... 디렉토리에 있는 ZSH 5.0.8에 속하는 모든 파일을 포함합니다. 시스템 도구는 1 /System/Links에 매핑되는 계층 구조 아래에 이러한 파일에 대한 기호 링크를 만듭니다 /usr. 이 PATH변수는 단일 통합 실행 가능 디렉터리만 포함하며 LD_LIBRARY_PATH사용되지 않습니다. 여러 버전의 소프트웨어가 동시에 공존할 수 있지만 bin/zsh지정된 이름( )을 가진 하나의 파일만 한 번에 활발하게 연결됩니다. 전체 경로를 통해 다른 사람에게 액세스할 수 있습니다.
또한 통합 실행 가능 디렉터리 등에 대한 호환성 심볼릭 링크 및 /bin매핑 세트도 있습니다 . /usr/bin이렇게 하면 런타임 시 소프트웨어 작업이 더 쉬워집니다. 커널 패치 GoboHide를 사용하면 이러한 호환성 심볼릭 링크를 파일 목록에서 숨길 수 있습니다(그러나 여전히 탐색 가능).
다른 답변을 찬성하면원하지 않는다커널 코드 수정 필요: GoboHide는 순전히 장식용이며 커널은 일반적으로 사용자 공간 경로²에 의존하지 않습니다. GoboLinux에는 사용자 정의 초기화 시스템이 있지만 이를 수행하는 데 반드시 필요한 것은 아닙니다.
슬로건은 항상 "파일 시스템은 패키지 관리자이다"였지만 시스템에는 상당히 일반적인 패키지 관리 도구도 있습니다. 그러나 cp, rm및 를 사용하여 모든 작업을 완료 할 수 있습니다 ln.
GoboLinux를 사용하고 싶다면 환영합니다. 하지만 이 팀은 소규모 개발 팀이라는 점을 지적하고 싶습니다. 이전에 원하는 소프트웨어 중 일부를 사용하고 싶어한 사람이 아무도 없다면 해당 소프트웨어가 패키지로 제공되지 않을 수도 있습니다. 좋은 소식은 시스템용 프로그램을 구축하는 것이 일반적으로 매우 쉽다는 것입니다(표준 "레시피"는 약 3줄 길이입니다). 나쁜 소식은 때때로 매우 복잡할 수 있다는 것입니다. 이에 대해서는 아래에서 자세히 설명하겠습니다.
출판
"출판물"이 있습니다. 나는 연설을 했다linux.conf.au 2010전체 시스템은 모든 것을 다루며 비디오에서 확인할 수 있습니다.오고프 mp4(또한 귀하의 로컬 Linux Australia 미러에도 있습니다);내가 쓴 메모산문이 되십시오. 유명한 "를 포함하여 오래된 문서도 있습니다.나는 무지하지 않다",존재하다고보리눅스 웹사이트, 이는 다양한 반대 의견과 문제를 해결합니다. 지금은 우리 모두가 덜 열정적이라고 생각하며 향후 릴리스에서는 /usr기본 위치를 심볼릭 링크로 채택할 것으로 예상됩니다.
닉 OS
닉 OS설치된 각 프로그램을 고유한 디렉토리에 넣습니다 /nix/store. 이러한 디렉토리의 이름은 다음과 같습니다 /nix/store/5rnfzla9kcx4mj5zdc7nlnv8na1najvg-firefox-3.5.4/. 프로그램으로 이어지는 전체 종속성 및 구성 세트를 나타내는 암호화 해시가 있습니다. 이 디렉터리에는 로컬 위치가 어느 정도 일반적인 위치에 있는 모든 관련 파일이 포함되어 있습니다.
또한 동시에 여러 버전을 보유하고 그 중 하나를 사용할 수 있습니다. NixOS는 반복 가능한 구성과 관련된 전체적인 철학을 가지고 있습니다. 즉, 기본적으로 처음부터 구성 관리 시스템이 내장되어 있습니다. 설치된 프로그램에 대한 올바른 세계를 사용자에게 제공하기 위해 일부 환경 작업에 의존합니다.
선형 FS
아주 간단해요처음부터 리눅스그리고 원하는 계층 구조를 정확하게 설정하세요. 디렉터리를 만들고 모든 것이 올바른 위치에 설치되도록 구성하세요. 나는 GoboLinux를 구축하는 실험에서 이 작업을 몇 번 수행했는데 일반 LFS보다 그리 어렵지 않습니다. 이 경우 호환성 심볼릭 링크를 만들어야 합니다. 그렇지 않으면 더 어려워지지만 정말로 원한다면 연합 설치를 주의 깊게 사용하면 이를 피할 수 있습니다.
하나쯤은 있을 것 같은 느낌LFS 팁예전에는 그런 말이 있었는데 지금은 찾을 수 없는 것 같아요.
타당성에 관하여
FHS의 특징은 표준이고 매우 일반적이며 작성 당시의 기존 사용법을 광범위하게 반영한다는 것입니다. 대부분의 사용자는 본질적으로 이 레이아웃을 따르지 않는 시스템을 사용하지 않습니다. 그 결과 많은 소프트웨어가 아무도 깨닫지 못하고 종종 전혀 의도하지 않은 잠재적인 종속성을 갖게 됩니다.
이 모든 스크립트에는 #!/bin/bash? Bash가 없으면 좋지 않습니다. 이것이 바로 GoboLinux가 이러한 모든 호환성 심볼릭 링크를 갖고 있는 이유입니다. 많은 소프트웨어가 구축 시 또는 비표준 레이아웃에서 실행될 때 실행에 실패하고 수정을 위해 패치가 필요하며 이는 종종 매우 침해적입니다.
기본 Autoconf 프로그램은 일반적으로 사용자가 지시하는 곳에 설치되며 올바른 프로그램을 자동으로 전달하는 것은 쉽습니다 --prefix. -휴대용 구성. CMake는 후자 범주의 주요 범죄자입니다. 즉, 이 세상에 살고 싶다면 다른 사람의 빌드 시스템에서 미리 수많은 지루한 작업을 수행할 준비가 되어 있어야 한다는 의미입니다. 컴파일 중에 생성된 파일을 동적으로 패치하는 것은 정말 번거로운 작업입니다.
런타임은 또 다른 이야기입니다. 많은 프로그램은 자신의 파일이나 다른 사람의 파일이 자신과 관련하여 또는 절대적으로 발견되는 위치에 대해 가정합니다. 일관된 보기를 제공하기 위해 심볼릭 링크를 사용하기 시작하면 많은 프로그램이 심볼릭 링크를 잘못 처리합니다(또는 때로는 도움이 되지 않는 올바르게 작동한다고 가정해 보겠습니다). 예를 들어 도구는 해당 심볼릭 링크 를 foobar읽는지 여부에 따라 두 위치가 다를 수 있으며 둘 중 하나가 올바르지 않을 수도 있습니다.baz../sbin
포괄적인 문제는 /usr/share목차입니다. 물론 공유 파일용이지만 각 프로그램을 고유한 접두사에 넣으면 실제로는 더 이상 공유되지 않습니다. 이로 인해 프로그램이 표준 아이콘 등을 찾을 수 없게 됩니다. GoboLinux는 다소 추악한 방식으로 이 문제를 처리합니다. 빌드 시 를 $prefix/share가리키는 심볼릭 링크가 있고 $prefix/Shared, 빌드 후에 링크는 전역 share디렉토리를 가리킵니다. 이제는 컴파일 타임 샌드박스 및 파일 이동 share(및 기타 디렉터리)을 사용하여 처리되지만 링크를 읽는 런타임 오류는 여전히 문제가 될 수 있습니다.
여러 프로그램 모음은 또 다른 문제입니다. GoboLinux는 GNOME을 완벽하게 작동시키지 못했고 NixOS도 그렇게 했다고 믿지 않습니다. 왜냐하면 레이아웃 상호 의존성이 너무 뿌리 깊게 박혀 있어서 모두 고치는 것이 어렵기 때문입니다.
그래서,네 가능해요, 하지만:
- 일을 처리하는 것만으로도 많은 일이 발생합니다.
- 일부 소프트웨어는 작동하지 않을 수 있습니다.
- 사람들은 당신을 재미있게 볼 것입니다.
이 모든 것이 당신에게 문제가 될 수도 있고 아닐 수도 있습니다.
버전 14.01에서는 /System/Index에 직접 매핑되는 이를 사용합니다 /usr. 향후 버전에서는 링크/인덱스 계층 구조를 삭제하고 /usr전체적으로 사용할 수 있을 것으로 생각됩니다.
/bin/sh² 기본적으로 존재 해야 합니다 .
답변2
둘 다고보리눅스(F.sb에서 언급) 및GNU 그래픽 사용자 인터페이스각 패키지의 디렉토리 구조와 바이너리의 "현재" 버전을 가리키는 기호 링크를 사용하는 배포판입니다.
안정적인 시스템을 원한다면 GoboLinux가 더 나은 선택인 것 같습니다. GNU guix는 프로덕션 준비가 되지 않았음을 분명히 합니다. GoboLinux는 수년 동안 사용되어 왔습니다. 나는 그것을 직접 시도한 적이 없습니다.
답변3
각 패키지에 파일 시스템의 자체 부분이 있는 경우 매우 크고 다루기 힘든 환경 변수 등이 필요합니다 PATH.LD_LIBRARY_PATH
물론, 이 방법으로 패키지를 직접 설치한 다음 다음과 같은 것을 사용할 수도 있습니다.환경 모듈그것이 여러분의 환경에 있는지 여부를 관리합니다. 그것이 제가 작업하는 과학 소프트웨어에 대해 우리가 하는 일이지만 시스템 소프트웨어에 대해서는 그렇게 하지 않습니다.
답변4
Linux FHS는 1980년대 후반 Sun과 기타 UNIX 회사가 내린 결정을 기반으로 합니다.
당시 중요한 변화 /usr/local/는 /opt// { bin! ! ...}libman
오늘날 /usr/bin이 쓰레기장으로 사용되고 있는 이유를 찾고 있다면 GNOME이 가장 책임 있는 프로젝트 중 하나라고 생각합니다.
32비트 라이브러리와 64비트 라이브러리에서 발생하는 현상은 FHS로 인해 발생한 것 같습니다.
Solaris /lib /usr/bin에서는 및 에 플랫폼별 하위 디렉토리를 도입했습니다 /usr/lib. Sun은 1988년부터 이러한 기본 개념을 강화해 왔습니다.