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


10

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.


9
@RandallStewart seu " imprevisível e disperso " é nosso posicionamento racional e não duplicação de DLLs.
RonJohn

1
Isso é baseado historicamente - principalmente para poder ter várias partições de discos montadas enquanto é possível inicializar com apenas o essencial necessário. Uma situação semelhante foi quando os BIOS do PC puderam ver apenas a primeira parte de discos rígidos muito grandes, de modo que uma partição separada contendo tudo o necessário para a inicialização foi colocada nessa primeira parte. Normalmente chamado "/ boot". Hoje, a necessidade de caixas de areia e aplicativos não confiáveis ​​resultou em uma repensação - veja, por exemplo, os snaps do Ubuntu.
Thorbjørn Ravn Andersen

9
Deixe-me ser o primeiro a salientar que o Windows atualmente não coloca todos os arquivos de cada programa no diretório smae. Além de "Arquivos de programas" e "Arquivos de programas (x86)", existem diretórios "Usuários \ <nome de usuário> \ Appdata" de "Local", "LocalLow" e "Roaming", entre outros. O Windows nem sempre usou uma pasta "Arquivos de Programas" para programas ou a utilizou consistentemente ao longo de seu histórico. * O nix é muito mais consistente no manuseio de arquivos ao longo do tempo.
YLearn

5
@JAB, concordou e entendeu isso. Eu estava apontando que a declaração do OP, a saber "Portanto, no Windows, todos os arquivos de cada programa estão agrupados no mesmo diretório" simplesmente não é verdadeira. Também não trouxe à discussão o registro do Windows, que também pode ser visto como armazenamento de configuração e outros dados sobre os programas do Windows e não faz parte do diretório "Arquivos de Programas".
YLearn

2
Linux organiza os arquivos dos programas instalados? Desde quando?
Hbbs #

Respostas:


17

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.

Obrigado. Estou muito interessado em como você organiza os programas a serem instalados /home/tomasz/bin/, consulte unix.stackexchange.com/questions/431793/…
Tim

Meu entendimento era que, embora a separação de /bine /usr/binfosse de fato evitar problemas com /usrdiretórios montados na rede , a separação de /usre /usr/localé para diferenciar arquivos fornecidos pelo fornecedor ( /usr) e arquivos instalados manualmente na própria máquina ( /usr/local) e não tinham nada a ver com os problemas de montagem de rede. Isso é preciso?
Keiji

4
@Keiji, o gerenciamento fornecedor versus local é o uso mais comum (e convencional) para essa distinção hoje em dia, mas se você observar as instalações UNIX tradicionais, a opção /usrfora da rede (vs /usr/localestar, bem, local ) não é ouvida. do.
Charles Duffy

tudo isso é uma má idéia em 2018
amara

7

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.


6
Existem vantagens convincentes que permanecem úteis hoje. Manter binários /usr/bin, arquivos de dados estáticos /usr/sharee arquivos que podem ser modificados /varou /usr/varsignifica que medidas de segurança podem ser usadas para impor que nada seja shareou varseja executável (usando noexecsinalizadores em suas montagens); que nada externo varpode ser modificado (em um sistema usando dm_veritymedidas semelhantes para gerar mídia assinada, somente leitura); etc.
Charles Duffy

3

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.


2

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.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.