Vamos esclarecer todas as pastas bin e sbin (do padrão de hierarquia do sistema de arquivos):

• /bin é para binários no nível do sistema
• /sbin é para outros binários no nível do sistema, principalmente para o carregador de inicialização e administradores de sistema
• /usr/bin é para binários não essenciais
• /usr/sbin- é aqui que a bagunça começa - não são ferramentas essenciais para os administradores de sistema? O que isso significa? Para experimentos?
• /usr/local/bin - nenhuma palavra sobre esta pasta
• /usr/local/sbin- programas de administração de sistema instalados localmente. Novamente? Que tal /usr/sbin?

Então a questão é: Por que há tantos diretórios e quais são os significados de /usr/sbin, /usr/local/sbine /usr/local/bin?

Muitos programas são distribuídos através de arquivos e temos que construí-los a partir do código fonte. Geralmente eles têm makefile, então é bem fácil. Esse processo envolve a criação de arquivos em usr / local / lib, usr / local / bin ... usr / local / o que for, sem criar pastas específicas para um determinado programa.

Por que é tão?

Acho que não está certo porque, se precisarmos remover o programa, teremos que excluir manualmente todos os seus arquivos, se o criador do programa não cuidar dele.

1. Estrutura de diretório

Isso deve ser abordado no padrão de hierarquia do sistema de arquivos ( 2.3 PDF )

/ bin / Binários de comando essenciais que precisam estar disponíveis no modo de usuário único;
            para todos os usuários, por exemplo, cat, ls, cp

/ sbin / Binários essenciais do sistema, por exemplo, init, ip, mount.

/ usr / bin / Binários de comando não essenciais (não necessários no modo de usuário único); 
            para todos os usuários

/ usr / sbin / Binários não essenciais do sistema, por exemplo, daemons para vários serviços de rede.

/ usr / local / Hierarquia terciária para dados locais, específicos para este host. 
            Normalmente possui subdiretórios adicionais, por exemplo, bin /, lib /, share /

2. Instalação

Eu uso um gerenciador de pacotes sempre que possível (por exemplo, yum ou apt-get). Isso é possível para um número muito grande de aplicativos; em alguns casos, você pode precisar adicionar um repositório. Minha segunda opção seria pacotes de nível inferior, como RPMs, e compilar a partir do código-fonte seria meu último recurso (mas algumas pessoas preferem isso)

Alguns gerenciadores de pacotes podem instalar a partir de RPMs (por exemplo yum install oddity.rpm)

Se você está compilando a partir do código-fonte, provavelmente não é um grande passo para criar seu próprio pacote, para que o instalador do sistema saiba o que você fez.

Então o seu problema se reduz a, por exemplo, yum remove packagename

A alternativa é manter boa documentação sobre todas as atividades do administrador de sistemas realizadas (eu mantenho um diário em um arquivo de texto)

As coisas em todos os diretórios * / sbin tendem a ser úteis apenas para administradores de sistema. Você pode mantê-los fora do seu caminho, se você for um usuário normal.

Os diretórios diferentes não fazem muito sentido se você tiver uma única máquina unix em um único disco, mas fazem mais sentido se você tiver um sistema grande e partições diferentes. Lembre-se de que muitos desses hábitos foram criados nos anos 80 e 90, quando os sistemas eram um pouco diferentes.

/sbintende a ser muito pequeno. Esses são os utilitários que você precisa quando realmente está na mangueira. Você colocaria isso em uma partição raiz mínima com / root e / lib. As coisas no / sbin costumavam estar vinculadas estaticamente, pois se a sua partição / usr for hospedada, qualquer aplicativo vinculado dinamicamente será inútil. O fsck está aqui e estático. Se você tem uma dependência de / usr, obviamente não pode fsck / usr /. Obviamente, se a partição raiz for processada, você estará muito ferrado. É por isso que essa é uma partição tão pequena - diminua as chances de um bloco de disco defeituoso usando muito poucos blocos aqui.

/usr/sbinOs binários são ferramentas sysadmin gerais, nas quais você pode pelo menos acessar o modo de usuário único e montar todos os seus volumes. Eles podem ser vinculados dinamicamente.

As partições separadas para / sbin (bem, / sbin on / partition) e / usr também fazem mais sentido quando você se lembra que o backup era muito caro no tempo e na fita. Se eles estivessem em partições separadas, você poderia agendá-las de maneira diferente.

/usr/localpode ser um sistema de arquivos em rede. Portanto, ferramentas sysadmin escritas localmente que podem ser compartilhadas em muitas máquinas às vezes entram em / usr / local / sbin. Obviamente, nenhum utilitário de fixação de rede pode ir até lá.

Novamente, muitas coisas faziam mais sentido em grandes máquinas em um ambiente de rede em máquinas gerenciadas com vários volumes, menos com uma máquina Linux em uma única partição raiz.

Você realmente deve ter sua segunda pergunta aqui em Superusuário. Não está relacionado ao primeiro.

Sim, ter arquivos em todo o lugar é uma porcaria. É por isso que existem muitas soluções de embalagem. O RedHat criou o RPM que é usado em qualquer lugar. Solaris teve seu formato de pacote. O HP / UX possuía o deles, e existe o apt e muitos outros formatos de pacote. Mantenha as coisas nos lugares certos (/ usr / bin, / usr / lib) conforme apropriado, mas permita fácil adição e remoção.

Para fonte, costumava haver ferramentas que permitiam configurar e instalar em um subdiretório de / usr / local e manipularia links simbólicos para / usr / local / bin para você. Desde a ampla proliferação de ferramentas de pacote, isso é menos necessário, e eu esqueci seus nomes.

Algumas pessoas gostam de instalar no / opt / packagename e manter tudo junto. O bom: tudo está em um diretório e uma desinstalação rm -rf /opt/packagename. A desvantagem disso é ter que adicionar / opt / packagename / bin ao PATH de todos, e o fato de que as pessoas geralmente não colocam / optam em uma partição separada e você preenche a partição raiz.

Minha opinião sobre o significado dos diretórios (da experiência com o Debian GNU Linux) é esta:

Primeira distinção: sé para superusuário

santes de um bindiretório indicar que ele contém ferramentas que normalmente são úteis apenas para administradores. Observe que, por exemplo, ifconfigtambém pertence a esta categoria e eu gosto de chamar ifconfigcomo usuário comum (para verificar se tenho um endereço IP / conectividade de rede), o que torna essa distinção não tão difícil quanto parece.

Segunda distinção: localé para "Dados locais"

Na prática, a distinção mais importante aqui é que os gerenciadores de pacotes do SO (como APT) instalam pacotes na /usrestrutura normal e não são /usr/localafetados. Isso permite que pacotes compilados localmente ou scripts internos da empresa fornecidos pelo administrador do sistema sejam colocados /usr/localonde nunca irão interferir nos arquivos empacotados corretamente.

É discutível se /usr/localdeve substituir os arquivos existentes da /usrestrutura normal , consulte É perigoso ter / usr / local / bin à frente de / usr / bin no CAMINHO? para mais detalhes sobre isso.

Terceira distinção: O nível superior /bine os /sbindiretórios.

No Debian, existe realmente o chamado UsrMerge . Costumava haver a diferença de que /bine /sbinestavam disponíveis no processo de inicialização anteriormente (pensar em /usrestar em um dispositivo de rede ou partição diferente, RAID etc), mas nowdays alguns sistemas Linux arrancar bem sem /usrrazão pela qual eu consideraria a distinção entre top- nível e /usrdiretórios de grande interesse histórico para o Linux.

Finalmente: os méritos e os problemas dos arquivos "dispersos".

Realmente não existe uma resposta "verdadeira" para isso. As vantagens do sistema de arquivos dispersos do Linux são estas:

• Todos os binários residem em poucos diretórios. Isso significa que você pode chamar todos os programas do shell. Compare o Windows, onde sempre é necessário editar a %PATH%variável de ambiente para adicionar qualquer programa de interesse. Vi ambientes de caminho muito longo no Windows.

• Todas as bibliotecas residem em um local central. Isso significa que eles não precisam ser instalados duas vezes quando usados ​​por vários aplicativos.

• Como o Linux é projetado, a maioria dos arquivos do sistema é rastreada por um gerenciador de pacotes , não há necessidade de manter uma visão geral dos arquivos do ponto de vista do usuário.

• Devido à FHS padronização, documentação também reside em lugares centrais sistemas permitindo assim man, infoe os arquivos LEIA-ME de apoio a funcionar como esperado.

• É mais fácil contar com a instalação de um programa em um local fixo. Todo mundo escreve #!/bin/sh -eou similar no início dos scripts e simplesmente funciona . Considere um sistema em que o shell vá para um diretório diferente: como alguém saberia qual nome levaria? Se estiver interessado, verifique as várias maneiras de instalar o Perl ou o LaTeX no Windows para ver o quão complicado isso pode ficar ...

As desvantagens que encontrei até agora são as seguintes:

• Normalmente, é mais difícil executar aplicativos "portably" no sentido de "aplicativos portáteis para Windows". No Linux, não é tão fácil copiar o programa para outro computador ... é preciso ter o pacote (que requer permissões de root) ou lidar com o LD_LIBRARY_PATHponto de apontar aplicativos para diferentes caminhos de pesquisa para as bibliotecas solicitadas.

• A instalação de várias versões do mesmo programa precisa ser explicitamente suportada, enquanto em sistemas com "um diretório por programa" isso costuma ser um problema menor.

• Gerenciar os arquivos sem um gerenciador de pacotes é suscetível a erros (como já mencionado).

Para responder à sua segunda pergunta:
Geralmente os programas são distribuídos com o chamado gerenciador de pacotes . Um gerenciador de pacotes geralmente busca pacotes binários (software compilado para uma determinada plataforma) e o lança em diretórios (existem alguns que baixam o código-fonte, compilam-no na sua máquina e instalam-no). Assim, o gerenciador de pacotes sabe onde os arquivos pertencentes a determinado "programa" (pacote) estão residindo e, quando você deseja remover o pacote, o gerenciador de pacotes se encarrega de limpar tudo.
Mesmo quando você compila o código-fonte sozinho com

make

e instale-o com

make install

você geralmente pode fazer

make uninstall

que exclui os arquivos do sistema de arquivos.