Po pierwsze, ogólne zastrzeżenie dotyczące konfliktu interesów: Jestem wieloletnim programistą GoboLinux.
Po drugie, bezpośrednie twierdzenie o wiedzy specjalistycznej w dziedzinie: jestem wieloletnim programistą GoboLinux.
Obecnie istnieje kilka różnych struktur. GoboLinux ma jeden, a narzędzia takie jak GNU Stow , Homebrew itp. Używają czegoś całkiem podobnego (głównie w przypadku programów użytkownika). NixOS stosuje także niestandardową hierarchię programów i filozofię życia. Jest to również dość popularny eksperyment LFS.
Opiszę je wszystkie, a następnie skomentuję z doświadczenia, jak to działa w praktyce („wykonalność”). Krótka odpowiedź brzmi: tak, jest to wykonalne, ale musisz tego naprawdę chcieć .
GoboLinux
GoboLinux ma strukturę bardzo podobną do tego, co opisujesz. Oprogramowanie jest instalowane w /Programs: /Programs/ZSH/5.0.8zawiera wszystkie pliki należące do ZSH 5.0.8, w zwykłych katalogach bin/ lib/ ... Narzędzia systemowe tworzą dowiązania symboliczne do tych plików w /System/Linkshierarchii, która jest odwzorowana na /usr¹. PATHZmienna zawiera tylko jeden zunifikowany katalog wykonywalny i LD_LIBRARY_PATHjest nieużywany. Wiele wersji oprogramowania może współistnieć jednocześnie, ale tylko jeden plik o danej nazwie ( bin/zsh) zostanie połączony jednocześnie. Możesz uzyskać dostęp do innych przez ich pełne ścieżki.
Zestaw dowiązania zgodnością również istnieje, więc /bini /usr/binmap do zjednoczonej katalogu plików wykonywalnych, i tak dalej. Ułatwia to życie oprogramowaniu w czasie wykonywania. Łata jądra, GoboHide, pozwala ukryć te dowiązania symboliczne kompatybilności przed listami plików (ale nadal możliwe do przejścia).
W przeciwieństwie do innej odpowiedzi, nie trzeba modyfikować kodu jądra: GoboHide jest czysto kosmetyczny, a jądro nie zależy ogólnie od ścieżek przestrzeni użytkownika². GoboLinux ma system inicjujący na zamówienie, ale nie jest to również wymagane.
Slogan zawsze brzmiał: „system plików jest menedżerem pakietów”, ale w systemie istnieją rozsądne zwykłe narzędzia do zarządzania pakietami. Można zrobić wszystko za pomocą cp, rmi ln, choć.
Jeśli chcesz korzystać z GoboLinux, nie ma za co. Zauważę jednak, że jest to niewielki zespół programistów i prawdopodobnie okaże się, że niektóre potrzebne oprogramowanie nie jest spakowane, jeśli nikt wcześniej nie chciał go używać. Dobrą wiadomością jest to, że generalnie dość łatwo jest zbudować program dla systemu (standardowy „przepis” ma około trzech linii); złą wiadomością jest to, że czasami jest to nieprzyjemnie skomplikowane, o czym opiszę poniżej.
Publikacje
Istnieje kilka „publikacji”. Dałem prezentację na linux.conf.au 2010 na temat systemu jako całości, która obejmuje wszystko ogólnie, co jest dostępne na wideo: ogv mp4 (również na twoim lokalnym serwerze lustrzanym Linux Australia); Zapisałem też swoje notatki do prozy. Istnieje również kilka starszych dokumentów, w tym słynny „ Nie jestem nieświadomy ” na stronie internetowej GoboLinux , który dotyczy niektórych zastrzeżeń i problemów. Wydaje mi się, że w dzisiejszych czasach wszyscy jesteśmy trochę mniej obojętni i podejrzewam, że przyszłe wydanie zostanie przyjęte /usrjako podstawowa lokalizacja dla dowiązań symbolicznych.
NixOS
NixOS umieszcza każdy zainstalowany program w swoim własnym katalogu /nix/store. Te katalogi są nazywane jakoś /nix/store/5rnfzla9kcx4mj5zdc7nlnv8na1najvg-firefox-3.5.4/- kryptograficzny skrót reprezentujący cały zestaw zależności i konfiguracji prowadzących do tego programu. Wewnątrz tego katalogu znajdują się wszystkie powiązane pliki, z lokalnymi mniej więcej normalnymi lokalizacjami.
Pozwala także na posiadanie wielu wersji jednocześnie i korzystanie z dowolnej z nich. NixOS ma całą filozofię związaną z odtwarzalną konfiguracją: zasadniczo ma w sobie system zarządzania konfiguracją od samego początku. Opiera się na pewnych manipulacjach środowiskowych, aby przedstawić użytkownikowi odpowiedni świat zainstalowanych programów.
LFS
Przejście przez Linux From Scratch i skonfigurowanie dokładnie takiej hierarchii, jaką chcesz, jest dość proste : wystarczy utworzyć katalogi i skonfigurować wszystko, aby zainstalować we właściwym miejscu. Zrobiłem to kilka razy, budując eksperymenty z GoboLinux i nie jest to znacznie trudniejsze niż zwykły LFS. W takim przypadku musisz utworzyć dowiązania symboliczne zgodności; w przeciwnym razie jest to znacznie trudniejsze, ale ostrożne korzystanie z łączników unii może prawdopodobnie tego uniknąć, jeśli naprawdę chcesz.
Wydaje mi się, że w pewnym momencie istniała wskazówka LFS , ale nie mogę jej teraz znaleźć.
W sprawie wykonalności
W FHS chodzi o to, że jest to standard, jest bardzo powszechny i zasadniczo odzwierciedla obecne użycie w momencie jego pisania. Większość użytkowników nigdy nie będzie w systemie, który zasadniczo nie przestrzega tego układu. Powoduje to, że wiele programów ma ukryte zależności, których nikt nie zdaje sobie sprawy, często zupełnie przypadkowo.
Wszystkie te skrypty z #!/bin/bash? Nic dobrego, jeśli nie masz tam Basha. Właśnie dlatego GoboLinux ma wszystkie te dowiązania symboliczne kompatybilności; to jest po prostu praktyczne. Wiele programów nie działa ani w czasie kompilacji, ani w czasie wykonywania w niestandardowym układzie, a następnie wymaga łatania w celu poprawienia, często dość natrętnie.
Twój podstawowy program Autoconf zazwyczaj instaluje się z radością, gdziekolwiek mu powiesz, i dość łatwo jest zautomatyzować proces przekazywania poprawnego --prefix. Inne systemy kompilacji nie zawsze są tak fajne, albo przez celowe pieczenie w hierarchii, albo przez wiodących autorów do napisania nieprzenośnej konfiguracji. CMake jest poważnym przestępcą w tej drugiej kategorii. Oznacza to, że jeśli chcesz żyć na tym świecie, musisz być przygotowany do wykonywania wielu pracowitych zadań w systemach budowania innych ludzi. Trudno jest dynamicznie łatać generowane pliki podczas kompilacji.
Runtime to kolejna sprawa. Wiele programów zakłada, że ich własne pliki lub pliki innych osób znajdują się albo względem nich, albo absolutnie. Kiedy zaczynasz używać dowiązań symbolicznych do prezentowania spójnego widoku, wiele programów ma błędy w ich obsłudze (lub czasami poprawne zachowanie, które nie jest dla ciebie pomocne). Na przykład narzędzie foobarmoże oczekiwać, że znajdzie bazplik wykonywalny obok niego lub w nim ../sbin. W zależności od tego, czy czyta swoje dowiązanie symboliczne, czy nie, mogą to być dwa różne miejsca i żadne z nich i tak może nie być poprawne.
Połączonym problemem jest /usr/sharekatalog. Oczywiście dotyczy udostępnionych plików, ale kiedy umieścisz każdy program pod własnym prefiksem, nie będą one już udostępniane. To prowadzi do tego, że programy nie mogą znaleźć standardowych ikon i tym podobnych. GoboLinux poradził sobie z tym w dość brzydki sposób: w czasie kompilacji $prefix/sharebył dowiązaniem symbolicznym $prefix/Shared, a po zbudowaniu odsyłał do sharekatalogu globalnego . Używa teraz piaskownicy w czasie kompilacji i przenoszenia plików, aby poradzić sobie z share(i innymi katalogami), ale błędy w czasie wykonywania odczytywania łączy mogą nadal stanowić problem.
Pakiety wielu programów to kolejny problem. GoboLinux nigdy nie sprawił, by GNOME działało w pełni i nie sądzę, że NixOS też tak ma, ponieważ współzależności układu są tak upieczone, że trudno jest je wszystkie wyleczyć.
Tak, jest to wykonalne , ale:
- Po prostu sprawienie, by rzeczy działały, wymaga sporo pracy.
- Niektóre programy mogą po prostu nigdy nie działać.
- Ludzie będą patrzeć na ciebie śmiesznie.
Wszystkie te mogą, ale nie muszą stanowić dla ciebie problemu.
¹ Używa się wersji 14.01 /System/Index, która mapuje bezpośrednio na /usr. Podejrzewam, że przyszła wersja może upuścić hierarchię linków / indeksów i korzystać z niej /usrwe wszystkich obszarach.
² /bin/shDomyślnie musi istnieć.