Jaka jest korzyść ze sposobu, w jaki Linux organizuje pliki zainstalowanych programów? [Zamknięte]

W systemie Windows dysk systemowy C:ma katalog program_files, w którym każdy program ma swój własny katalog.

W Linuksie, pod /usr/i /usr/local/są /bin, /etc, /share, /src, itp.

Tak więc w systemie Windows wszystkie pliki każdego programu są pogrupowane w tym samym katalogu, podczas gdy w systemie Linux są pliki tego samego typu ze wszystkich programów.

Wydaje mi się, że sposób, w jaki system Windows organizuje zainstalowane programy, jest bardziej logiczny niż w przypadku systemu Linux, a zatem zainstalowanymi programami łatwiej zarządzać ręcznie.

Jaka jest korzyść ze sposobu, w jaki Linux organizuje pliki zainstalowanych programów? Dzięki.

Mam to pytanie, gdy mam problem z tym, jak zorganizować zainstalowane programy w $ HOME, aby powłoka szukała ich podczas uruchamiania? , gdzie próbuję uporządkować swoje programy w $HOMEsposób podobny do systemu Windows, ale mam problem z określeniem ścieżek wyszukiwania programów.

W Linuksie różne lokalizacje zwykle, jeśli są dobrze utrzymane, odzwierciedlają logikę. Na przykład.:

• /bin zawiera najbardziej podstawowe narzędzia (programy)
• /sbin zawiera najbardziej podstawowe programy administracyjne

Oba zawierają elementarne polecenia używane podczas uruchamiania i podstawowego rozwiązywania problemów. I tutaj widzisz pierwszą różnicę. Niektóre programy nie są przeznaczone do użytku przez zwykłych użytkowników.

Następnie zajrzyj do środka /usr/bin. Tutaj powinieneś znaleźć większy wybór poleceń (programów), zwykle więcej niż 1000 z nich. Są to standardowe narzędzia, ale nie tak istotne jak te w /bini /sbin.

/usr/binzawiera polecenia, podczas gdy pliki konfiguracyjne znajdują się gdzie indziej. To zarówno oddziela jednostki funkcjonalne (programy), jak i ich pliki konfiguracyjne i inne, ale pod względem funkcjonalności użytkownika jest to przydatne, ponieważ nie mieszanie poleceń z niczym innym pozwala na proste użycie PATHzmiennej wskazującej pliki wykonywalne. Wprowadza również jasność. Cokolwiek jest, powinno być wykonywalne.

Spójrz na moim PATH,

$ echo "$PATH" | perl -F: -anlE'$,="\n"; say @F'
/home/tomas/bin
/usr/local/bin
/usr/bin
/bin
/usr/local/games
/usr/games

Istnieje dokładnie sześć lokalizacji zawierających polecenia, które mogę wywoływać bezpośrednio (tj. Nie według ich ścieżek, ale według nazw plików wykonywalnych).

• /home/tomas/bin to mój prywatny katalog w moim katalogu domowym dla moich prywatnych plików wykonywalnych.
• /usr/local/bin Wyjaśnię osobno poniżej.
• /usr/bin jest opisane powyżej.
• /bin jest również opisane powyżej.
• /usr/local/gamesto połączenie /usr/local(które zostanie wyjaśnione poniżej) i gier
• /usr/gamessą gry. Nie należy ich mieszać z plikami wykonywalnymi narzędzi, mają one swoje osobne lokalizacje.

Teraz do /usr/local/bin. Ten jest nieco śliski i został już tutaj wyjaśniony: Co to jest / usr / local / bin? . Aby to zrozumieć, musisz wiedzieć, że folder /usrmoże być współdzielony przez wiele komputerów i montowany z lokalizacji sieciowej. Komendy tam nie są potrzebne podczas uruchamiania, jak wspomniano wcześniej, w przeciwieństwie do tych w /bin, więc lokalizację można zamontować na późniejszych etapach procesu uruchamiania. Można go również zamontować w trybie tylko do odczytu. /usr/local/binz drugiej strony dotyczy programów instalowanych lokalnie i musi mieć możliwość zapisu. Tak więc, podczas gdy wiele komputerów sieciowych może współdzielić ten /usrkatalog ogólny , każdy z nich będzie miał swój własny /usr/localzamontowany wewnątrz wspólnego /usr.

Na koniec spójrz na PATHmojego użytkownika root:

# echo "$PATH" | perl -F: -anlE'$,="\n"; say @F'
/usr/local/sbin
/usr/local/bin
/usr/sbin
/usr/bin
/sbin
/bin

Zawiera te:

• /usr/local/sbin, który zawiera polecenia administracyjne tego typu /usr/local
• /usr/local/bin, które są tymi samymi, których może używać zwykły użytkownik. Ponownie ich typ można opisać jako /usr/local.
• /usr/sbin są nieistotnymi narzędziami administracyjnymi.
• /usr/bin są nieistotnymi narzędziami administracyjnymi i zwykłymi użytkownikami.
• /sbin są niezbędnymi narzędziami administracyjnymi.
• /bin są niezbędnymi narzędziami administratora i zwykłego użytkownika.

W dzisiejszych czasach myślę, że jest to dziedzictwo historyczne od klasycznego systemu UNIX.

W pierwszych wersjach UNIX programy nie były tak duże jak obecnie. Programy często składały się z jednego pliku wykonywalnego, który korzysta z bibliotek systemowych. Tak więc nikt nie pomyślał o programach, które będą składały się z kilku własnych bibliotek. Główną biblioteką była biblioteka C i każdy program wiedział o jej lokalizacji.

Również środowisko UNIX zostało uznane za gotowy produkt (do przygotowania dokumentacji). Dlatego ścieżki do wszystkich narzędzi zostały naprawione.

Niektóre zalety stałych ścieżek w dniach HDD (dysku twardego) są obecnie dostępne. Jeśli FSH (hierarchia systemu plików) podzieli się na osobne partycje dysku i umieści partycje z plikami binarnymi i bibliotekami w pobliżu podstawowych sektorów dysku twardego, czas uruchamiania programu będzie nieco krótszy.

To, co postrzegasz jako nowoczesny system uniksowy, nie jest tak naprawdę tradycyjne.

Normalnie hierarchie byłyby dość minimalne /i miałyby /usrtylko narzędzia systemowe, a następnie programy były instalowane osobno w podkatalogu /usr/local, a następnie udostępniane poprzez tworzenie dowiązań symbolicznych.

Bardzo typową instalacją oprogramowania GNU była kompilacja i instalacja

./configure
make
make install prefix=/usr/local/DIR/program-1
cd /usr/local/DIR
stow program-1

Narzędzie GNU stow tworzy dowiązania symboliczne, aby oprogramowanie było dostępne na standardowej ścieżce, bez konieczności dodawania katalogów do zmiennej PATH (podobnie jak Windows i cruft ma tendencję do gromadzenia się tam).

Nowoczesne dystrybucje Linuksa dostarczają jednak wszystko jako gotowe pakiety, więc programy stały się częścią „systemu”. Ponieważ menedżer pakietów zajmuje się instalacją, nie ma potrzeby tworzenia dowiązań symbolicznych, a rozdzielanie programów nie ma pożytecznego celu (ale spowalnia uruchamianie programu, ponieważ trzeba skanować wiele małych katalogów).

Jeśli chcesz zainstalować oprogramowanie w swoim katalogu domowym, sugeruję, abyś używał do tego GNU stow - pozwoli to na oddzielenie programów, co jest rozsądne, jeśli nie używasz menedżera pakietów.

Mój tradycyjny setup bo to jeden katalog ~/software/DIR, że instalacja programów w, a następnie za pomocą Stow wnętrze DIRstworzyć ~/software/bin, ~/software/shareitd. Oznacza to mam tylko dodać ~/software/bindo zmiennej PATH, aby wszystkie moje zainstalowane oprogramowanie.

Posługiwać się:

./configure --prefix=~/software
make
make install prefix=~/software/DIR/program-1
cd ~/software/DIR
stow program-1

zainstalować, jeśli program jest zgodny z konwencjami GNU.

Wygląda na to, że mówisz o stylu dzielenia poszczególnych plików według celu ( /usr/bindla plików wykonywalnych, /usr/libbibliotek), a nie według pakietu aplikacji (kompilator C ++ w jednym katalogu , programy do edycji obrazów w innym). Podczas gdy w systemach uniksowych wynika to z wielu przyczyn historycznych, istnieją również siły, które sprawiają, że systemy uniksowe są skłonne do tego: menedżerowie pakietów, którzy zarządzają większością programów w systemie.

W systemie Windows, historycznie i nadal dość często, aplikacje były odpowiedzialne za zapewnienie własnego instalatora, a zwłaszcza dezinstalatora, a nawet teraz często nie rejestrują się na żadnej centralnej liście aplikacji. W takiej sytuacji generalnie lepiej jest, aby aplikacja miała własny katalog dla jak największej liczby plików. Pomaga to uniknąć konfliktów z innymi aplikacjami, choć nie zawsze to działa (szczególnie w przypadku bibliotek DLL ).

Z drugiej strony systemy uniksowe mają od lat 90. generalnie jednego akceptowanego menedżera pakietów i grupę zapewniającą dużą ilość powszechnie używanego oprogramowania za pośrednictwem tego menedżera pakietów. (Oficjalne menedżery pakietów dla różnych Uniksów obejmują yumi aptdla systemów Linux, pkgsrcNetBSD i portsFreeBSD. Często komercyjne systemy Unix również kończą się nieoficjalnym, ale powszechnie akceptowanym menedżerem pakietów, takim jak brewMacOS.)

Zaletą tych menedżerów pakietów jest to, że mogą śledzić każdy plik w systemie w różnych „podkatalogach”, których są właścicielami. Ponieważ pojedyncza grupa przypisuje tutaj nazwę i lokalizację każdego pliku, wszyscy mogą korzystać z małego zestawu katalogów udostępnionych między nimi. Daje to różne korzyści, szczególnie w zakresie udostępniania plików między aplikacjami i utrzymywania niskiej liczby ścieżek potrzebnych do wyszukiwania bibliotek i plików wykonywalnych.

To powiedziawszy, istnieje również długa tradycja instalacji „osobnego katalogu na aplikację” w Uniksie, zwykle w /optkatalogu.