it-swarm.dev

Jaký je důvod adresáře `/ usr`?

Jaké je zdůvodnění „unixových systémových prostředků“, nebo /usr adresář, jak je popsáno zde , který duplikuje mnoho názvů adresářů v kořenovém adresáři /?

Můj účel: Instaloval jsem Oracle JDK již podeváté a tentokrát jsem se rozhodl jej jednoduše umístit pod /home/user a já si jen trochu přečtu, abych zjistil, jestli to není špatný nápad na jednom uživatelském počítači.

111
H2ONaCl

Existuje krátká verze a dlouhá verze vaší odpovědi ...

Krátká verze:

Jak již váš odkaz řekl, /usr je místo pro systémové , soubory pouze pro čtení . Takže veškerý nainstalovaný software tam jde. Neduplikuje žádné názvy / až na /bin a /lib, ale původně s jiným účelem: /bin, /lib je pouze pro binární soubory a knihovny potřebné pro zavedení , zatímco /usr/bin, /usr/lib je pro všechny ostatní spustitelné soubory a knihovny. (nyní buďte dobrým klukem a neptejte se na /sbin, toto je konec konců krátká verze)

V dnešní době se rozdíl mezi „požadovaným pro bootování“ a nezmenšil, protože většina moderních distribucí, včetně Ubuntu, se nemůže správně spustit bez několika souborů z /usr. A proto dochází k silnému pohybu směrem ke sloučení /usr/bin a /bin, tak pravděpodobně v blízké budoucnosti (asi Ubuntu 12.10?) /bin bude symbolickým odkazem na /usr/bin.

Ale možná si pleteš /usr a /usr/local? Protože ano, existuje (a měla by být) šarže duplikovaných názvů adresářů. Více o tom později ...

Dlouhá verze:

V 70. letech, v Unixu (ano, Unix, daleko před Linuxem), měly diskety málo místa (ne HD, pamatujete?), A v daném okamžiku se počet binárních souborů v systému a jejich velikosti příliš rozrostl do bodu, který by ne umístit jeden disk a vývojáři je museli rozdělit na několik médií a vytvořit pro ně nové body připojení. /bin souborový systém byl plný, takže nainstalovali nové binární soubory na ... /usr/bin. A /usr byl v té době jejich ... uživatelským adresářem!

Poté, co se stalo (téměř trapné a často vyprávěné jako vtip/lore) rozdělení, začali vytvářet „umělá“ ospravedlnění (a kritéria), aby rozhodli, co by mělo jít k /bin a co by šlo na /usr/bin. Neformální pravidlo bylo: „podstatné“ věci jdou na /bin, „zbytek“ přejde na /usr/bin. Stejné s /lib. Nebylo to dlouho předtím /usr se zaplnil řadami souvisejícími se systémem a smíchal se s uživateli. Tím pádem /home se narodil, aby si zachoval všechny návyky související s uživateli a udržel /usr čisté pouze pro systémové „věci“.

To bylo dlouho předtím, než existovala FHS. Když to bylo vytvořeno, to přijalo (a formalizovalo) aktuální tradici a udržovalo jméno /usr, i když v té době už s uživatelem nic nemělo nic společného. Takže ano, vymyšlená jména " [~ # ~] u [~ # ~] NIX s ource r epository "nebo" [~ # ~] u [~ # ~] NIX s ystem r zdroje „jsou všechny vytvořená jména a je příliš pozdě na jejich přejmenování. (ale ne příliš pozdě na sloučení /bin k tomu)

"Dobře, co /usr/sbin? ", ptáš se. Sakra, doufal jsem, že jsi zapomněl. Ok ... /usr/sbin je pro příkazy, které mohou být (nebo mají smysl pouze tehdy) prováděny uživatelem root, jako mount a fdisk.

"Ale není to skoro stejné jako /bin? ". Ano, jasně, ale ...

"Počkejte, proč existuje /sbin také? Nedává to žádný smysl! “. No, je to kvůli ... err .. hummu ..

Podívej, tříhlavá opice za tebou!

Dobře, doufejme, že jste se dost rozptýlili. Posouvat se...

(pokud si myslíte, že podvádím, ano, máte pravdu. Ale stejně tak jsou to „oficiální“ odpovědi) základní příkazy, které mohou být provedeny pouze rootem a musí být k dispozici ještě před připojením / "). Pravda je: linka je opravdu rozmazaná a existuje spousta starých jmen, která se" zasekla "a teď je docela těžké se jich zbavit.

Více o Případ pro /usr sloučit , z systemd docs:

Historické zdůvodnění pro/bin,/sbin a/lib oddělené od/usr již dnes neplatí. Byli rozděleni, aby vybrali nástroje na rychlejším pevném disku (což bylo malé, protože to bylo dražší) a aby obsahovaly všechny nástroje potřebné k připojení pomalejšího/usr oddílu. Dnes již musí initramfs připojit samostatný oddíl/usr již během brzkého startu, čímž se ospravedlní oddělovací bod. Navíc mnoho nástrojů v/bin a/sbin ve stavu quo již ztratilo schopnost běžet bez předem připojeného/usr. Neexistuje žádný platný důvod k tomu, aby byl operační systém rozšířen do více hierarchií, ztratil svůj účel.

A úžasné čtení o /usr split a jeho zdůvodnění, Rob Landley:

Pochopení rozdělení bin, sbin, usr/bin, usr/sbin split

Dnes

V současnosti, pokud jde o instalační adresáře, je nejlepším způsobem, jak porozumět, přemýšlet takto:

  • /usr - všechny celosystémové soubory určené pouze pro čtení nainstalované (nebo poskytované) OS

  • /usr/local - celosystémové soubory určené pouze pro čtení nainstalované místním správcem (obvykle vy). Proto většina jmen adresářů z /usr jsou zde duplikovány.

  • /opt - zvěrstvo určené pro celý systém, software jen pro čtení a samostatný software. To znamená, že software, který nerozděluje své soubory na bin, lib, share, include, jako by se měl dobře chovaný software.

  • ~/.local - protějšek uživatele /usr/local, to je: software nainstalovaný (a pro) každým uživatelem

  • ~/.local/opt - protějšek uživatele /opt

Takže kam instalovat software?

Výše uvedený seznam je již poloviční odpovědí na vaši otázku Oracle JDK, přinejmenším dává několik vodítek. Kontrolní seznam „Kam mám nainstalovat software X?“ :

  • Je to zcela samostatný software s jedním adresářem, jako je Eclipse IDE a další stažené aplikace Java aplikace), a chcete, aby byl dostupný všem uživatelům? Poté nainstalujte do /opt

  • Stejné jako výše, ale nezajímá vás ostatní uživatelé a já chci nainstalovat pouze pro vašeho uživatele? Poté nainstalujte do ~/.local/opt

  • Jeho soubory se dělí na několik adresářů, například bin a share, jako je tradiční software kompilovaný a nainstalovaný s ./configure && make && Sudo make install a měl by být dostupný všem uživatelům? Poté nainstalujte do /usr/local

  • Stejné jako výše, ale pouze pro uživatele? Poté nainstalujte do ~/.local

  • Software nainstalovaný operačním systémem nebo prostřednictvím správců balíků (jako je Software Center), a co je nejdůležitější, , která lokální modifikace může být přepsána, když správce aktualizací upgraduje na novou verzi ? Jde to na /usr

Poznámky:

  • Toto vysvětluje, proč je výchozí předpona instalace kompilovaného softwaru /usr/local a proč byste ji měli změnit na ./configure --prefix=$HOME/.local při instalaci softwaru pouze pro vašeho vlastního uživatele

  • Možná jste si všimli, že všechny výše uvedené adresáře jsou jen pro čtení (kromě, samozřejmě, když nainstalovat/odebrat software). Zapisovatelné soubory (jako konfigurační soubory) obvykle přejdou na /etc (pro systémový software) a ~/.config (pro nastavení jednotlivých uživatelů). Ačkoli mnoho staršího softwaru (a bohužel i některých moderních) používá ~/.<software-name>, zaplňuje vaši domovskou složku miliardami dir a souborů.

  • ~/.local a ~/.config nejsou součástí specifikace FHS. FHS se nezabývá domovskou složkou uživatele. Jsou pokusem XDG, další standardní organizace zaměřené na desktopové prostředí (jako Gnome, KDE a Unity), aby se pokusili nastavit některé konvence týkající se struktury domu uživatele. Ne veškerý software se k němu drží (například ~/.local/bin není ve výchozím nastavení uživatele $PATH, zatímco logicky by to mělo) , a žádný uživatel není nucen jej sledovat, ale oba získají mnoho výhod interoperability, pokud ano.

Doufám, že to pomůže trochu objasnit věci. Neváhejte se zeptat na cokoli, abych mohl zlepšit odpověď!

(a také doufám, že mě puristé nezabijí pro takový nesmírně neformální jazyk a vysvětlení. Bylo to úmyslné a jistě má mnoho nepřesností, ale já ano věřte, že je to dobrý způsob, jak přimět nováčka ke stručnému pochopení principů instalačních adresářů)

183
MestreLion