Qual é o benefício da maneira como o Linux organiza os arquivos dos programas instalados? [fechadas]

Question

No Windows, a unidade do sistema C: tem um diretório program_files , sob o qual cada programa possui seu próprio diretório.

No Linux, em /usr/ e /usr/local/ , existem /bin, /etc, /share, /src , etc.

Assim, no windows, todos os arquivos de cada programa são agrupados no mesmo diretório, enquanto no Linux, arquivos do mesmo tipo de todos os programas são.

Eu sinto que o modo como o Windows organiza os programas instalados é mais lógico do que o Linux, e assim os programas instalados são mais fáceis de gerenciar manualmente.

Qual é o benefício da maneira como o Linux organiza os arquivos dos programas instalados? Obrigado.

Eu tenho essa pergunta quando tenho o problema de Como organizar programas instalados em $ HOME para shell para procurá-los quando executá-los? , onde tento organizar meus programas em $HOME no caminho do Windows, mas tem algum problema em especificar os caminhos de busca para os programas.

    

Answer 1

No Linux, os diferentes locais geralmente, quando bem mantidos, espelham alguma lógica. Por exemplo:

• /bin contém as ferramentas mais básicas (programas)
• /sbin contém os programas de administração mais básicos

Ambos contêm os comandos elementares usados pela inicialização e solução de problemas fundamentais. E aqui você vê a primeira diferença. Alguns programas não devem ser usados por usuários comuns.

Em seguida, dê uma olhada em /usr/bin . Aqui você deve encontrar uma maior escolha de comandos (programas), geralmente mais de 1000 deles. Eles são ferramentas padrão, mas não tão essenciais quanto os de /bin e /sbin .

/usr/bin contém os comandos, enquanto os arquivos de configuração residem em outro lugar. Isso separa as entidades funcionais (programas) e suas configurações e outros arquivos, mas em termos de funcionalidade do usuário, isso é útil, pois ter os comandos não misturados com qualquer outra coisa permite o uso simples da variável PATH apontando para o executáveis. Também introduz clareza. O que quer que seja deve ser executável.

Veja meu PATH

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

Existem exatamente seis locais contendo os comandos que eu posso chamar diretamente (ou seja, não por seus caminhos, mas pelos nomes de seus executáveis).

• /home/tomas/bin é meu diretório privado na minha pasta pessoal para meus executáveis privados.
• /usr/local/bin explicarei separadamente abaixo.
• /usr/bin é descrito acima.
• /bin também é descrito acima.
• /usr/local/games é uma combinação de /usr/local (a ser explicado abaixo) e jogos
• /usr/games são jogos. Para não serem misturados com executáveis de utilitário, eles têm seus locais separados.

Agora para /usr/local/bin . Este é um pouco escorregadio, e já foi explicado aqui: O que é / usr / local / bin? . Para entendê-lo, você precisa saber que a pasta /usr pode ser compartilhada por várias máquinas e montada a partir de um local de rede. Os comandos não são necessários na inicialização, como observado anteriormente, ao contrário dos que estão em /bin , portanto, o local pode ser montado em estágios posteriores do processo de inicialização. Ele também pode ser montado de maneira somente leitura. /usr/local/bin , por outro lado, é para os programas instalados localmente e precisa ser gravável. Assim, enquanto muitas máquinas de rede podem compartilhar o diretório geral /usr , cada uma delas terá seu próprio /usr/local montado dentro da comum /usr .

Por fim, dê uma olhada no PATH do meu usuário root:

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

Ele contém estes:

• /usr/local/sbin , que contém os comandos admin do tipo /usr/local
• /usr/local/bin , que são os mesmos que o usuário comum pode usar. Novamente, o tipo deles pode ser descrito como /usr/local .
• /usr/sbin são os utilitários de administração não essenciais.
• /usr/bin são a administração não essencial e utilitários de usuário regulares.
• /sbin são as ferramentas administrativas essenciais.
• /bin são as ferramentas essenciais do administrador e do usuário regular.

Answer 2

Hoje em dia, acho que isso é herança histórica do clássico UNIX.

Nas primeiras versões do UNIX, os programas não eram tão grandes quanto nos dias de hoje. Os programas geralmente consistiam em um arquivo executável que usava bibliotecas do sistema. Então, ninguém pensou em programas que serão compostos por algumas bibliotecas próprias. A biblioteca principal era a biblioteca C e todos os programas sabiam da sua localização.

Além disso, o ambiente UNIX foi considerado como produto acabado (para preparação de documentação). Portanto, os caminhos para todas as ferramentas foram corrigidos.

Alguns benefícios de caminhos fixos nos dias de HDD (Disco Rígido) estão presentes nos dias de hoje. Se o FSH (File System Hierarchy) se dividir em partições de disco separadas e colocar partições com binários e bibliotecas perto dos principais setores do HDD, o tempo de inicialização do programa será um pouco mais rápido.

    

Answer 3

O que você vê como um sistema moderno semelhante ao Unix não é realmente tradicional.

Normalmente, as hierarquias / e /usr seriam mínimas apenas com utilitários do sistema, e os programas são instalados separadamente em um subdiretório de /usr/local e, em seguida, disponibilizados pela criação de links simbólicos.

Uma configuração muito típica para o software GNU era compilar e instalar com

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

O utilitário stow do GNU cria links simbólicos para disponibilizar o software no caminho padrão, sem precisar adicionar nenhum diretórios para a variável PATH (como o Windows faz e cruft tende a acumular lá).

As distribuições Linux modernas, no entanto, enviam tudo como pacotes prontos, de modo que os programas se tornaram parte do "sistema". Como o gerenciador de pacotes cuida da instalação, não há necessidade de links simbólicos, e a separação de programas não serve para fins úteis (mas desaceleraria a inicialização do programa, já que muitos diretórios pequenos teriam que ser verificados).

Se você quiser instalar o software em seu diretório pessoal, sugiro que você use o GNU stow também - isso permitirá que você mantenha seus programas separados, o que é sensato se você não estiver usando um gerenciador de pacotes.

Minha configuração tradicional para isso é um diretório ~/software/DIR no qual eu instalo os programas e, em seguida, uso a opção DIR para criar ~/software/bin , ~/software/share etc. Isso significa que só preciso adicionar ~/software/bin ao Variável PATH para obter todos os meus softwares instalados.

Uso:

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

para instalar se o programa seguir as convenções GNU.

    

Answer 4

Você parece estar falando sobre o estilo de dividir arquivos individuais por finalidade ( /usr/bin para executáveis, /usr/lib para bibliotecas) em vez de por pacote de aplicativos (compilador C ++ em um diretório, programas de edição de imagem em outro). Enquanto nos sistemas Unix grande parte da razão para este histórico, há também as forças atuais que tendem a tornar os sistemas Unix-like inclinados para isso: gerenciadores de pacotes que gerenciam a maioria dos programas em um sistema.

No Windows, historicamente e ainda hoje, os aplicativos têm sido responsáveis por fornecer seu próprio instalador e, principalmente, o desinstalador, e mesmo agora com frequência não se registram em nenhuma lista central de aplicativos. Em uma situação como essa, geralmente é melhor que um aplicativo tenha seu diretório "próprio" para o maior número possível de arquivos. Isso ajuda a evitar conflitos com outros aplicativos, embora isso nem sempre funcione (especialmente no caso de DLLs ) .

Por outro lado, os sistemas Unix, desde os anos 90, têm em geral um único gerenciador de pacotes aceito e um grupo fornece uma grande quantidade de softwares comumente usados através deste gerenciador de pacotes. (Gerentes de pacotes oficiais para vários Unices incluem yum e apt para sistemas Linux, pkgsrc para NetBSD e ports para FreeBSD. Frequentemente sistemas Unix comerciais também acabam com um gerenciador de pacotes não oficial mas amplamente aceito, como brew para MacOS.

Esses gerenciadores de pacotes têm a vantagem de poder rastrear cada arquivo do sistema nos vários subdiretórios que eles "possuem". Como um único grupo está atribuindo o nome e a localização de todos os arquivos aqui, todos eles podem usar um pequeno conjunto de diretórios compartilhados entre eles. Isso oferece várias vantagens, especialmente nas áreas de compartilhamento de arquivos entre aplicativos e baixo número de caminhos que você precisa para procurar por bibliotecas e arquivos executáveis.

Dito isso, há uma longa tradição de instalação de "diretório separado por aplicativo" no Unix, geralmente sob o diretório /opt .