Por que os softwares costumam manter dados locais em $ HOME / .appname?

1

A maioria dos aplicativos que eu geralmente instalo (opam, carga, vscode, julia, ...) mantém um armazenamento local na minha pasta pessoal. Existe uma razão para essa preferência? Ou melhor, há desvantagens nas alternativas?

Por exemplo, às vezes, é sugerido que tais arquivos devem estar localizados em / var, ou em ~ / .local / share, mas pode haver problemas ou aborrecimentos ao usar essas pastas na aplicação "cross-distro".

Você conhece algum desses possíveis problemas?

[qualquer resposta a qualquer uma das três perguntas que fiz aqui seria satisfatória]

    
por KiriaKasis 08.02.2018 / 17:45

1 resposta

1

Em uma postagem do Google+ por Rob Pike, Uma lição de atalhos , é dada esta explicação:

Long ago, as the design of the Unix file system was being worked out, the entries . and .. appeared, to make navigation easier. I'm not sure but I believe .. went in during the Version 2 rewrite, when the file system became hierarchical (it had a very different structure early on). When one typed ls, however, these files appeared, so either Ken or Dennis added a simple test to the program. It was in assembler then, but the code in question was equivalent to something like this:

    if (name[0] == '.') continue;

This statement was a little shorter than what it should have been, which is

    if (strcmp(name, ".") == 0 || strcmp(name, "..") == 0) continue;

but hey, it was easy.

Two things resulted.

First, a bad precedent was set. A lot of other lazy programmers introduced bugs by making the same simplification. Actual files beginning with periods are often skipped when they should be counted.

Second, and much worse, the idea of a "hidden" or "dot" file was created. As a consequence, more lazy programmers started dropping files into everyone's home directory. I don't have all that much stuff installed on the machine I'm using to type this, but my home directory has about a hundred dot files and I don't even know what most of them are or whether they're still needed. Every file name evaluation that goes through my home directory is slowed down by this accumulated sludge.

I'm pretty sure the concept of a hidden file was an unintended consequence. It was certainly a mistake.

(For those who object that dot files serve a purpose, I don't dispute that but counter that it's the files that serve the purpose, not the convention for their names. They could just as easily be in $HOME/cfg or $HOME/lib, which is what we did in Plan 9, which had no dot files. Lessons can be learned.)

Então, o que eu entendo é que:

Como esses "arquivos de ponto" ficaram invisíveis, outros programadores entraram e decidiu que o lugar para armazenar seus preciosos dados de configuração estava nos arquivos de ponto junto com os arquivos . e .. . Como no começo a hierarquia de arquivos não foi muito evoluída, todos eles acabaram no diretório $ HOME, e bem rápido isso se tornou uma convenção não escrita à qual todos se conformavam, seguindo nos passos dos pais fundadores.

Isso deu origem a monstruosidades como:

Referência:

História do Linux: como os arquivos Dot se tornaram arquivos ocultos

    
por 08.02.2018 / 18:17