Jakie są alternatywy dla FHS?

Od ponad 15 lat jestem użytkownikiem Linuksa, ale nienawidzę z pasją struktury katalogów. Nie wiem jak to /usr/binjest wysypiskiem dla plików binarnych i bibliotekami w /usr/lib, /usr/lib32, /usr/libx32, /lib, /lib32itd ... Losowe rzeczy w /usr/shareitd. To jest głupie i mylące. Ale niektórym się to podoba i smaki różnią się.

Chcę strukturę katalogów, w której każdy pakiet jest izolowany. Zamiast tego wyobraź sobie, że smok odtwarzacza multimedialnego ma własną strukturę:

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

Lub:

/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/...

Dostajesz punkt. Jakie są moje opcje? Czy jest jakaś dystrybucja Linuksa, która używa czegoś takiego jak mój schemat? Czy niektóre dystrybucje można zmodyfikować, aby działały tak, jak chcę (Gentoo?), Czy potrzebuję LFS? Czy istnieje jakikolwiek stan techniki w tej dziedzinie? Podobnie jak publikacje dotyczące tego, czy program jest wykonalny czy niewykonalny?

Nie szukam OS X. :) Ale zainspirowany OS X jest całkowicie w porządku.

Edit : Nie mam pojęcia, jak PATH, LD_LIBRARY_PATHi innych zmiennych środowiskowych, które zależą od małego zestawu ścieżek powinna wypracować. Wydaje mi się, że jeśli mam zainstalowaną Kate, edytor KDE, /software/kate/bin/x86/bin/kateto jestem w stanie wpisać pełną ścieżkę do pliku binarnego, aby go uruchomić. Jak to powinno działać w przypadku bibliotek dynamicznych i dlopenwywołań, nie wiem, ale nie może to być nierozwiązywalnym problemem inżynieryjnym.

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ć.

Zarówno GoboLinux (o którym wspomniał F.sb), jak i GNU guix to dystrybucje, które wykorzystują strukturę katalogów poszczególnych pakietów wraz z dowiązaniami symbolicznymi do wskazania „bieżącej” wersji pliku binarnego.

GoboLinux wydaje się być lepszym rozwiązaniem, jeśli chcesz mieć stabilny system. Guix GNU wyraźnie mówi, że nie jest jeszcze gotowy do produkcji. GoboLinux istnieje od lat. Nigdy też nie próbowałem.

sprawdź GoboLinux .

jeśli chcesz zmienić strukturę katalogów, powinieneś zmienić kod jądra, proces rozruchu, poziomy uruchamiania katalogów na podstawie plików rc i menedżera pakietów, a następnie strukturę katalogów.

Linux FHS jest oparty na decyzjach firmy Sun i innych firm z UNIX pod koniec lat 80.

Ważną zmianą w tym czasie było porzucenie /usr/local/i wprowadzenie /opt// { bin! lib! man! ...}

Jeśli szukasz powodu, dla którego / usr / bin jest dziś wykorzystywany jako miejsce zrzutu, uważam, że GNOME jest jednym z najbardziej odpowiedzialnych projektów.

To, co stało się z bibliotekami 32-bitowymi i 64-bitowymi, wydaje się być spowodowane przez FHS.

Solaris wprowadził podkatalogi specyficzne dla platformy w /lib /usr/bin i /usr/lib. Czy chcesz, aby firma Sun ulepszyła podstawową koncepcję z 1988 roku.

Jeśli każdy pakiet miał swoją własną część systemu plików, to trzeba bardzo dużych i nieporęcznych zmienne środowiskowe PATH, LD_LIBRARY_PATHi podobne.

Możesz oczywiście sam zainstalować pakiety w ten sposób, a następnie użyć czegoś takiego jak Moduły GNU, aby zarządzać, czy są one w twoim środowisku, czy nie, i to właśnie robimy dla oprogramowania naukowego, w którym pracuję, ale nie robimy tego dla oprogramowanie systemowe.