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

10

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.

— Tim
źródło

9

@RandallStewart Twoje „ nieprzewidywalne i rozproszone ” to nasze racjonalne umieszczanie i brak powielania bibliotek DLL.

— RonJohn

1

Jest to historycznie oparte - głównie po to, aby mieć możliwość zamontowania kilku partycji dysków, jednocześnie mając możliwość rozruchu z niezbędnymi niezbędnymi elementami. Podobna sytuacja miała miejsce, gdy BIOS systemu PC widział tylko pierwszą część bardzo dużych dysków twardych, więc oddzielna partycja zawierająca wszystko, co potrzebne do rozruchu została umieszczona w tej pierwszej części. Zwykle nazywany „/ boot”. Dzisiaj potrzeba piaskownic i niezaufanych aplikacji spowodowała, że zostało to ponownie przemyślane - patrz np. Przystawki Ubuntu.

— Thorbjørn Ravn Andersen

9

Pozwól, że jako pierwszy zwrócę uwagę, że system Windows obecnie nie umieszcza wszystkich plików każdego programu w katalogu smae. Oprócz „Program Files” i „Program Files (x86)” istnieją między innymi katalogi „Users \ <nazwa użytkownika> \ Appdata” „Local”, „LocalLow” i „Roaming”. System Windows również nie używał folderu „Program Files” dla programów ani nie używał go konsekwentnie w swojej historii. * Nix jest znacznie bardziej spójny w obsłudze plików w czasie.

— YLearn

5

@JAB, zgodził się i rozumiem to. Zwróciłem uwagę, że wypowiedź OP, a mianowicie: „W systemie Windows wszystkie pliki każdego programu są pogrupowane w tym samym katalogu” po prostu nie jest prawdą. Nie wziąłem również do dyskusji rejestru systemu Windows, który może być również postrzegany jako przechowywanie konfiguracji i innych danych o programach Windows i nie jest częścią katalogu „Program Files”.

— YLearn

2

Linux organizuje pliki zainstalowanych programów? Od kiedy?

— hobbs

17

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.

Dzięki. Jestem bardzo zainteresowany tym, jak organizujesz programy do zainstalowania /home/tomasz/bin/, zobacz unix.stackexchange.com/questions/431793/…

— Tim

Rozumiałem, że chociaż oddzielenie /bini /usr/binrzeczywiście miało uniknąć problemów z /usrkatalogami podłączonymi do sieci , oddzielenie /usri /usr/localsłuży do rozróżnienia plików dostarczonych przez dostawcę ( /usr) i plików zainstalowanych ręcznie na samym komputerze ( /usr/local) i nie miało to nic wspólnego z problemy z podłączeniem do sieci. Czy to jest dokładne?

— Keiji,

4

@Keiji, zarządzanie kontra dostawca lokalny jest obecnie najczęstszym (i konwencjonalnym) zastosowaniem tego rozróżnienia, ale jeśli spojrzysz na tradycyjne instalacje UNIX, /usr-off-a-network (vs /usr/localbycie, cóż, lokalnie ) nie jest niespotykane z.

— Charles Duffy

to wszystko taki zły pomysł w 2018 roku

— amara

7

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.

— Jurij Gonczaruk
źródło

6

Istnieją przekonujące zalety, które pozostają użyteczne do dziś. Utrzymywanie plików binarnych w /usr/bin, plików danych statycznych /usr/sharei plików, które można modyfikować, /varlub /usr/varoznacza, że można zastosować środki bezpieczeństwa w celu wymuszenia, aby nic w sharelub nie varbyło wykonywalne (poprzez użycie noexecflag dla ich montowań); nic zewnętrznego nie varmoże być modyfikowane (w systemie wykorzystującym dm_veritylub podobnym mierniku do generowania podpisanych nośników tylko do odczytu); itp.

— Charles Duffy

3

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.

— Simon Richter
źródło

2

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.

— cjs
źródło