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

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

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

Portanto, 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.

Eu sinto que a maneira como o Windows organiza os programas instalados é mais lógica que a do Linux e, portanto, 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 ao ter o problema de Como organizar programas instalados em $ HOME para shell para procurá-los ao executá-los? , onde tento organizar meus programas no $HOMEcaminho do Windows, mas tenho algum problema ao especificar os caminhos de pesquisa para os programas.

No Linux, os diferentes locais geralmente, quando bem conservados, refletem 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 ​​na inicialização e na solução de problemas fundamentais. E aqui você vê a primeira diferença. Alguns programas não devem ser usados ​​por usuários regulares.

Então dê uma olhada /usr/bin. Aqui você deve encontrar uma grande variedade de comandos (programas), geralmente mais de 1000 deles. Eles são ferramentas padrão, mas não tão essenciais quanto as de /bine /sbin.

/usr/binconté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 PATHvariável que aponta para os executáveis. Também introduz clareza. O que quer que seja deve ser executável.

Dê uma olhada no 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 que contêm os comandos que eu posso chamar diretamente (ou seja, não pelos caminhos, mas pelos nomes dos executáveis).

• /home/tomas/bin é o meu diretório privado na minha pasta pessoal para os meus executáveis ​​particulares.
• /usr/local/bin Vou explicar separadamente abaixo.
• /usr/bin está descrito acima.
• /bin também é descrito acima.
• /usr/local/gamesé uma combinação de /usr/local(a ser explicada abaixo) e jogos
• /usr/gamessão jogos. Para não serem misturados com os executáveis ​​de utilitários, 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 entender, você precisa saber que a pasta /usrpode ser compartilhada por muitas 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, diferentemente dos apresentados /bin, portanto, o local pode ser montado nos estágios posteriores do processo de inicialização. Também pode ser montado em modo somente leitura. /usr/local/bin, por outro lado, é para os programas instalados localmente e precisa ser gravável. Portanto, embora muitas máquinas de rede possam compartilhar o /usrdiretório geral , cada uma delas terá sua própria /usr/localmontagem dentro do comum /usr.

Por fim, dê uma olhada no PATHmeu 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 de administrador do tipo /usr/local
• /usr/local/bin, que são os mesmos que o usuário comum pode usar. Novamente, seu tipo 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 regulares do usuário.
• /sbin são as ferramentas administrativas essenciais.
• /bin são as ferramentas essenciais do administrador e do usuário comum.

Atualmente, acho que essa é uma 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 usa bibliotecas do sistema. Portanto, ninguém pensou em programas que consistiriam em duas bibliotecas próprias. A biblioteca principal era a biblioteca C e todos os programas sabiam sobre a localização.

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

Alguns benefícios dos caminhos fixos nos dias de HDD (Disco Rígido) estão presentes atualmente. Se o FSH (Hierarquia do sistema de arquivos) 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 início do programa será um pouco mais rápido.

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

Normalmente, não haveria bastante mínimo /e /usrhierarquias com utilitários do sistema apenas, e os programas são então instalados separadamente em um subdiretório /usr/local, e depois disponibilizados através da 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 de armazenamento GNU cria links simbólicos para disponibilizar o software no caminho padrão, sem a necessidade de adicionar nenhum diretório à variável PATH (como o Windows faz, e o cruft tende a se acumular lá).

As distribuições modernas do Linux, no entanto, enviam tudo como pacotes prontos, então 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 nada (mas atrasaria a inicialização do programa, pois muitos diretórios pequenos precisariam ser verificados).

Se você deseja instalar o software em seu diretório pessoal, sugiro que você use o GNU stow também para isso - 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 esse é um diretório no ~/software/DIRqual instalo programas e, em seguida, uso o stow inside DIRpara criar ~/software/bin, ~/software/shareetc. Isso significa que só preciso adicionar ~/software/binà variável PATH para obter todo o meu software instalado.

Usar:

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

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

Você parece estar falando sobre o estilo de dividir arquivos individuais por finalidade ( /usr/binpara executáveis, /usr/libbibliotecas) e não por pacote de aplicativos (compilador C ++ em um diretório, programas de edição de imagens em outro). Enquanto nos sistemas Unix grande parte da razão desse histórico, também existem forças atuais que tendem a fazer com que sistemas semelhantes ao Unix se inclinem para isso: gerenciadores de pacotes que gerenciam a maioria dos programas em um sistema.

No Windows, historicamente e ainda bastante hoje, os aplicativos têm sido responsáveis ​​por fornecer seu próprio instalador e, principalmente, desinstalador, e mesmo agora frequentemente não se registram em nenhuma lista de aplicativos central. Em uma situação como essa, geralmente é melhor para um aplicativo ter 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 (principalmente no caso de DLLs ).

Os sistemas Unix, por outro lado, desde os anos 90, em geral, cada um tinha um único gerenciador de pacotes aceito e um grupo fornecendo uma grande quantidade de software comumente usado por meio desse gerenciador de pacotes. (Os gerenciadores de pacotes oficiais para vários Unices incluem yume aptpara sistemas Linux, pkgsrcpara NetBSD e portsFreeBSD. Geralmente, os sistemas Unix comerciais também acabam com um gerenciador de pacotes não oficial, mas amplamente aceito, como brewno MacOS.)

Esses gerenciadores de pacotes têm a vantagem de poder rastrear todos os arquivos do sistema nos vários subdiretórios que eles "possuem". Como um único grupo está atribuindo o nome e o local de cada arquivo 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 de manter baixo o número de caminhos necessários para procurar bibliotecas e arquivos executáveis.

Dito isto, também existe uma longa tradição de instalação de "diretório separado por aplicativo" no Unix, geralmente no /optdiretório.