FHS 的替代品有哪些？
我是超過 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 編輯器Kate，/software/kate/bin/x86/bin/kate那麼我可以輸入二進製文件的完整路徑來啟動它。它應該如何用於動態庫和dlopen呼叫，我不知道，但這不是一個無法解決的工程問題。
首先，預先聲明利益衝突免責聲明：我是一名長期的 GoboLinux 開發人員。
其次，對領域專業知識的預先聲明：我是一名長期的 GoboLinux 開發人員。
目前使用有幾種不同的結構。GoboLinux有一個，像GNU Stow、Homebrew等工具使用非常相似的東西（主要用於使用者程序）。NixOS還為程序和生活哲學使用了非標準的層次結構。這也是一個相當常見的 LFS 實驗。
我將描述所有這些，然後從經驗中評論這在實踐中是如何運作的（“可行性”）。簡短的回答是，是的，這是可行的，但你必須真的想要它。
GoboLinux
GoboLinux 的結構與您描述的非常相似。軟體安裝在
/Programs：/Programs/ZSH/5.0.8包含屬於 ZSH 5.0.8 的所有文件，位於通常的bin/lib/… 目錄中。系統工具在層次結構下創建指向這些文件的符號連結，這些文件/System/Links映射到/usr¹。該PATH變數僅包含單個統一的可執行目錄，並且LD_LIBRARY_PATH未使用。多個版本的軟體可以同時共存，但一次只能bin/zsh主動連結一個給定名稱 ( ) 的文件。您可以通過他們的完整路徑訪問其他人。還存在一組兼容性符號連結，因此
/bin並/usr/bin映射到統一的執行檔目錄，依此類推。這使軟體在執行時的工作更加輕鬆。核心更新檔 GoboHide 允許從文件列表中隱藏這些兼容性符號連結（但仍可遍歷）。與另一個答案相反，您不需要修改核心程式碼：GoboHide 純粹是裝飾性的，核心通常不依賴於使用者空間路徑²。GoboLinux 確實有一個定制的初始化系統，但這也不是必需的。
標語一直是“文件系統是包管理器”，但係統中有相當普通的包管理工具。
cp不過，您可以使用、rm和來完成所有操作ln。如果您想使用 GoboLinux，非常歡迎您。不過，我會指出，它是一個小型開發團隊，如果以前沒有人願意使用它，您可能會發現您想要的某些軟體沒有打包。好消息是為系統建構程序通常相當容易（標準“配方”大約三行）；壞消息是，有時它非常複雜，我將在下面詳細介紹。
出版物
有一些“出版物”。我在linux.conf.au 2010上做了一個關於整個系統的展示，它涵蓋了所有內容，可以在影片中找到：ogv mp4（也在你當地的 Linux 澳大利亞鏡像上）；我還把筆記寫成了散文。GoboLinux 網站上還有一些較舊的文件，包括著名的“我不是一無所知”，其中解決了一些反對意見和問題。我認為這些天我們都沒有那麼熱情了，我懷疑未來的版本將採用作為符號連結的基本位置。
/usr尼克斯作業系統
NixOS將每個已安裝的程序放入
/nix/store. 這些目錄的名稱類似於/nix/store/5rnfzla9kcx4mj5zdc7nlnv8na1najvg-firefox-3.5.4/- 有一個加密雜湊表示整個程序的依賴項和配置集。該目錄內是所有相關文件，在本地具有或多或少的正常位置。它還允許您同時擁有多個版本，並使用其中的任何一個。NixOS 擁有與之相關的可重複配置的整體理念：它本質上從一開始就嵌入了一個配置管理系統。它依賴於一些環境操作來向使用者呈現正確的已安裝程序世界。
LFS
從頭開始瀏覽Linux並準確設置您想要的層次結構非常簡單：只需創建目錄並配置所有內容以安裝在正確的位置。我在建構 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預設存在。