Qual é a razão para o diretório '/ usr'?

Question

Qual é a razão para os "recursos do sistema unix", ou /usr directory, como descrito aqui , que duplica muitos dos nomes de diretório sob o diretório raiz / ?

Meu objetivo: estou instalando o Oracle JDK pela enésima vez e decidi que desta vez colocá-lo em /home/user e estou lendo um pouco para ver se é uma má idéia em uma única máquina de usuário .

    

Answer 1

Há a versão curta e a versão longa da sua resposta ...

Versão resumida:

Como seu link já disse, /usr é um local para arquivos em todo o sistema , somente leitura . Então todo o seu software instalado vai para lá. Ele não duplica nomes de / exceto /bin e /lib , mas, originalmente, com uma finalidade diferente: /bin, /lib é somente para binários e bibliotecas necessários para inicialização , enquanto /usr/bin, /usr/lib é para todos os outros executáveis e bibliotecas. (agora seja um bom menino e não pergunte sobre /sbin , esta é a versão curta depois de tudo)

Hoje em dia, a distinção entre "required for booting" diminuiu, já que a maioria das distros modernas, incluindo o Ubuntu, não pode inicializar corretamente sem vários arquivos de /usr . E é por isso que há um strong movimento para mesclar /usr/bin e /bin , então provavelmente no futuro próximo (Ubuntu 12.10 talvez?)% Co_de% será um link simbólico para /bin .

Mas talvez você esteja confundindo /usr/bin e /usr ? Porque sim, há (e deve ser) um lote de nomes de diretório duplicados. Mais sobre isso depois ...

Versão longa:

De volta aos anos 70, no Unix (sim, Unix, bem antes do Linux), os disquetes tinham pouco espaço (não HD, lembra?), e em um dado momento os binários do sistema cresciam em número e tamanho em um ponto eles não cabiam em um único disco e os desenvolvedores precisavam dividi-los em várias mídias e, assim, criar novos pontos de montagem para eles. /usr/local filesystem estava cheio, então eles instalaram os novos binários em ... /bin . E /usr/bin era, naquele momento, seu diretório ... usuário !

Depois que a divisão (quase constrangedora e muitas vezes contada como piada / lore) aconteceu, eles começaram a criar justificativas (e critérios) "artificiais" para decidir o que iria para /usr e o que iria para /bin . A regra informal era: coisas "essenciais" vão para /usr/bin , "o resto" vai para /bin . Mesmo com /usr/bin . Não demorou muito para que /lib se tornasse repleto de diretórios relacionados ao sistema, misturados com diretórios de usuário. Assim, /usr nasceu, para manter todos os dirs relacionados ao usuário e manter /home clean apenas para "coisas" do sistema.

Isso foi muito antes da existência da ESF. Quando foi criado, adotou (e formalizou) a tradição atual e manteve o nome /usr , embora naquela época já não tivesse mais nada a ver com "usuário". Então, sim, os nomes especiais " U NIX s ource r epositório" ou " U NIX s ystem r esources "são todos nomes inventados, e é tarde demais para renomeá-lo mesmo assim. (mas não é tarde demais para mesclar /usr a ele)

"Ok, e quanto a /bin ?" , você pergunta. Porra, eu estava esperando que você tivesse esquecido. Ok ... /usr/sbin é para comandos que só podem ser executados pelo usuário /usr/sbin (ou só são significativos quando), como root e mount .

"Mas isso não é quase o mesmo que fdisk ?" . Sim, claro, mas ...

"Espere, então por que há um /bin também? Não faz nenhum sentido!" . Bem, isso é por causa de ... err .. humm ..

Olha, um macaco de três cabeças atrás de você!

Ok, espero que você tenha se distraído o suficiente. Seguindo em frente ...

(se você acha que estou trapaceando, sim, você está correto. Mas a resposta "oficial" também é "comandos essenciais que só podem ser executados pelo root e devem estar disponíveis antes mesmo de você montar /sbin "). A verdade é: a linha está realmente embaçada, e há muitos nomes legados que acabaram de ser "colados" e agora é muito difícil se livrar deles.

Mais sobre o Caso para o / merge , de /usr docs:

  

A justificativa histórica para um / bin, / sbin e / lib separado de / usr não se aplica mais hoje. Eles foram divididos para ter ferramentas selecionadas em um disco rígido mais rápido (que era pequeno, porque era mais caro) e para conter todas as ferramentas necessárias para montar a partição / usr mais lenta. Hoje, uma partição / usr separada já deve ser montada pelo initramfs durante o boot inicial, fazendo assim a justificativa para uma discussão fracionada. Além disso, muitas das ferramentas em / bin e / sbin no status quo já perderam a capacidade de executar sem um / usr pré-montado. Não há mais razão válida para que o sistema operacional se espalhe por várias hierarquias, ele perdeu seu propósito.

E uma leitura incrível sobre o systemd split e seu raciocínio, por Rob Landley:

Entendendo o bin, sbin, usr / bin, divisão usr / sbin

Hoje em dia

Atualmente, em relação aos diretórios de instalação, sua melhor maneira de entender é pensar assim:

• /usr - todos os arquivos somente leitura do sistema instalados por (ou fornecidos pelo) sistema operacional

• /usr - arquivos somente leitura do sistema instalados pelo administrador local (geralmente, você). E é por isso que a maioria dos nomes de diretório de /usr/local são duplicados aqui.

• /usr - uma atrocidade destinada a todo o sistema, somente leitura, e software autônomo. Ou seja, softwares que não dividam seus arquivos sobre /opt , bin , lib , share como software bem-comportado devem.

• include - a contrapartida por usuário de ~/.local , ou seja: software instalado por (e para) cada usuário

• /usr/local - a contrapartida por usuário de ~/.local/opt

Então, onde instalar o software?

A lista acima já é metade da resposta da sua pergunta do Oracle JDK, pelo menos dá várias pistas. A lista de verificação para "Onde devo instalar o software X?" :

• É um software de diretório único completamente independente, como o Eclipse IDE e outros aplicativos java baixados, e você quer que ele esteja disponível para todos os usuários? Em seguida, instale em /opt

• O mesmo que acima, mas você não se importa com outros usuários e deseja instalá-los apenas para seu usuário? Em seguida, instale em /opt

• Seus arquivos são divididos em vários diretórios, como ~/.local/opt e bin , como os softwares tradicionais compilados e instalados com share , e devem estar disponíveis para todos os usuários? Em seguida, instale em ./configure && make && sudo make install

• O mesmo que acima, mas apenas para seu usuário? Em seguida, instale em /usr/local

• Software instalado pelo sistema operacional ou por meio de gerenciadores de pacotes (como o Centro de Software) e, mais importante, quais modificações locais podem ser sobrescritas quando o gerenciador de atualizações as atualiza para uma nova versão ? Vai para ~/.local

Notas:

• Isso explica por que o prefixo de instalação padrão do software compilado é /usr e por que você deve alterá-lo para /usr/local ao instalar o software apenas para seu próprio usuário

• Você deve ter notado que os diretórios all acima são somente leitura (exceto, é claro, quando você instala / remove software). Os arquivos graváveis (como arquivos de configuração) geralmente vão para ./configure --prefix=$HOME/.local (para software de todo o sistema) e /etc (para configurações por usuário). Embora muitos softwares legados (e, infelizmente, alguns modernos também) usem ~/.config , bagunçando sua pasta pessoal com bilhões de diretórios e arquivos.

• ~/.<software-name> e ~/.local não fazem parte da especificação do FHS. O FHS não lida com a pasta base do usuário. Eles são uma tentativa do XDG, outra organização padrão voltada para ambientes de desktop (como Gnome, KDE e Unity), para tentar definir algumas convenções em relação à estrutura da casa do usuário. Nem todo software adere a ele (por exemplo, ~/.config não está no padrão do usuário ~/.local/bin , enquanto pela lógica deveria) , e nenhum usuário é forçado a segui-lo, mas ambos ganham muitos benefícios de interoperabilidade, se o fizerem.

Espero que isso ajude a esclarecer um pouco as coisas. Sinta-se à vontade para perguntar qualquer coisa para que eu possa melhorar a resposta!

(e também espero que os puristas não me matem por uma linguagem e uma explicação extremamente informais. Foi intencional, e certamente tem muitas imprecisões, mas eu acredito que é uma boa maneira de fazer um recém-chegado tem uma breve visão geral sobre os princípios de diretórios de instalação)