Por que há uma mistura de links simbólicos e hardlinks em / bin?

Question

Eu entendo a diferença técnica entre links simbólicos e hardlinks, essa é uma questão sobre seu uso na prática, particularmente estou curioso para saber por que ambos são usados em condições aparentemente similares: o diretório /bin .

Aqui está um fragmento de listagem no meu sistema:

~$ ls -lai /bin
total 10508
32770 drwxr-xr-x  2 root root    4096 Jun 14 11:47 .
    2 drwxr-xr-x 28 root root    4096 Sep  6 13:15 ..
  119 -rwxr-xr-x  1 root root  959120 Mar 28 22:02 bash
   2820 -rwxr-xr-x  3 root root   31112 Dec 15  2011 bunzip2
  127 -rwxr-xr-x  1 root root 1832016 Nov 16  2012 busybox
   2820 -rwxr-xr-x  3 root root   31112 Dec 15  2011 bzcat
 6191 lrwxrwxrwx  1 root root       6 Dec 15  2011 bzcmp -> bzdiff
 5640 -rwxr-xr-x  1 root root    2140 Dec 15  2011 bzdiff
 5872 lrwxrwxrwx  1 root root       6 Dec 15  2011 bzegrep -> bzgrep
 3520 -rwxr-xr-x  1 root root    4877 Dec 15  2011 bzexe
 6184 lrwxrwxrwx  1 root root       6 Dec 15  2011 bzfgrep -> bzgrep
 5397 -rwxr-xr-x  1 root root    3642 Dec 15  2011 bzgrep
   2820 -rwxr-xr-x  3 root root   31112 Dec 15  2011 bzip2
 2851 -rwxr-xr-x  1 root root   10336 Dec 15  2011 bzip2recover
 6189 lrwxrwxrwx  1 root root       6 Dec 15  2011 bzless -> bzmore
 5606 -rwxr-xr-x  1 root root    1297 Dec 15  2011 bzmore

Eu indentei os hardlinks para o mesmo inode para melhor visibilidade. Assim, os links simbólicos são usados no caso de bzcmp , bzegrep , bzfgrep , bzless e hardlinks no caso de bzip2 , bzcat , bunzip2 ?

Eles são todos arquivos regulares (não diretórios), residem dentro de um sistema de arquivos, são utilitários do sistema e são feitos para trabalhar com a mesma coisa: arquivos bzip. As razões para o uso de hardlinks / links simbólicos neste caso específico são puramente históricas ou estou faltando alguma coisa?

Esclarecimento da minha pergunta:

Não estou perguntando sobre:

• As diferenças técnicas entre links simbólicos e hardlinks
• As vantagens e desvantagens teóricas de cada uma delas

Essas perguntas foram abordadas em outros tópicos sobre SO. Estou tentando entender por que diferentes decisões foram tomadas em um caso específico: para um grupo de utilitários de sistema relacionados. Tecnicamente, todos eles poderiam ter sido links simbólicos ou todos eles poderiam ter sido hardlinks, ambas as opções funcionariam (e em ambos os casos um programa ainda pode descobrir como ele foi invocado via argv[0] ). Eu quero entender a intenção aqui, se houver alguma.

Relacionado:

• Por que os links físicos existem?

Answer 1

Por que usar hardlinks vs. links simbólicos

Existem basicamente 3 vantagens de usar links de hardware sobre links simbólicos neste cenário.

Hard links

1. Com um link físico, o link aponta para o inode diretamente.
2. Os hard links são como ter várias cópias do executável, mas usam apenas o espaço em disco de um.
3. Você pode renomear qualquer ramificação do link físico sem quebrar nada.

Links simbólicos

1. O link aponta para o objeto (que, por sua vez, aponta para o inode).
2. Eles podem abranger sistemas de arquivos, enquanto hardlinks não podem.

Vantagens da vinculação em geral

Esses links existem porque muitos executáveis se comportam de maneira diferente com base em como foram chamados. Por exemplo, os dois comandos bzless e bzmore são, na verdade, um único executável, bzmore . O executável se comportará de maneira diferente, dependendo de quais nomes foram usados para invocá-lo.

Isso é feito por vários motivos. Aqui estão algumas das mais óbvias:

1. Mais fácil desenvolver um único executável do que muitos
2. economiza espaço em disco
3. Mais fácil de implantar

Por que ambos estão sendo usados?

A escolha de qualquer um, neste aplicativo específico, é discutível. Qualquer um deles pode facilitar o recurso de agir como um alias para que um único executável possa ser sobrecarregado. Essa é realmente a principal característica que está sendo explorada pelos desenvolvedores dos vários programas aqui.

Ao olhar para o FHS (Filesystem Hierarchy Standard) , ele também especifica Desta forma, que pode ser qualquer um.

trecho

If /bin/sh is not a true Bourne shell, it must be a hard or symbolic link to the real shell command.

The rationale behind this is because sh and bash mightn't necessarily behave in the same manner. The use of a symbolic link also allows users to easily see that /bin/sh is not a true Bourne shell.

...

...

If the gunzip and zcat programs exist, they must be symbolic or hard links to gzip. /bin/csh may be a symbolic link to /bin/tcsh or /usr/bin/tcsh.

Referências

• Por que os links simbólicos de reinicialização, desligamento e desligamento são systemctl?

Answer 2

Parece que você está tentando descobrir, a partir de práticas existentes, se existe uma regra não técnica que lhe diga que tipo de link usar. (Eu digo não técnico porque você já conhece as razões técnicas para usar um sobre o outro.)

A resposta é que não há outra regra. Esse exemplo que você apontou do pacote bzip2 do Ubuntu mostra que muitos desenvolvedores os misturam sem muita premeditação. Isso ocorre porque não há uma orientação strong além das diferenças técnicas, e essas diferenças são pequenas.

Pessoalmente, prefiro usar links simbólicos, sempre, porque estou disposto a pagar por sua pequena sobrecarga em troca de sua natureza de autodocumentação.

Outros desenvolvedores escolherão links físicos para as pequenas eficiências que eles fornecem.

Esse problema é muito parecido com espaços x guias ou digitação dinâmica vs. estática ou Emacs vs. vi , mas não é interessante o suficiente para desencadear uma guerra santa . Como as batalhas mais interessantes, há razões para escolher uma das opções, mas a menos que você tenha alguém lhe dizendo qual delas usar, você pode escolher aquela que faz mais sentido para você.