Por que certas convenções de nomenclatura são tão inconsistentes no Linux? [fechadas]

Question

Parece que o conjunto geral de arquivos de log, changelog, readme e config no Linux é chamado de forma muito inconsistente. Isso sempre me faz pensar, por que os desenvolvedores * nix não decidem sobre um esquema de nome de arquivo comum há muito tempo? Eu sinto que é desnecessariamente irritante ter que lembrar exatamente como um arquivo é nomeado em relação a, digamos, configurações.

Por exemplo, aqui está a convenção de nomenclatura da configuração: Encontramos this , this.cnf , this.conf , this.config ou nenhum, perdendo para o underscore this_config realms ou mesmo ocasionalmente o Windowsy this.cfg estilo. Considerando a diversidade acima, qual é a abordagem mais aceita para nomear configs? O mesmo pode ser dito / pedido de logs, changelogs, readmes, etc.

A maioria dos scripts e binários parece bem definida com um esquema consistente, então o que fez as configurações tomarem o caminho mais difícil? Aconteceu alguma coisa no passado que dividiu a multidão dev em nomear campos de convenções, ou consistência "terciária" como essa nunca valeu a pena, devido à natureza aberta e abordagem de espírito livre do Linux?

    

Answer 1

Considering the diversity above, what is the most accepted approach for naming configs?

O que você quiser chamá-los. As extensões de arquivo não importam muito além de permitir que um administrador saiba o que o arquivo provavelmente é. Um humano provavelmente saberá que *.cfg e *.conf são provavelmente arquivos de configuração.

O *.cnf que eu só vi com o MySQL é um desvio único que você deve perguntar aos desenvolvedores do MySQL / MariaDB.

Did something happen back in the day that divided the dev crowd into naming convention camps, or was "tertiary" consistency like this just never worth pursuing due to the open nature and free spirit approach of Linux?

Provavelmente não é algo que a maioria das pessoas consideraria importante. A maioria das pessoas usa *.conf hoje em dia ( nginx , udev , apache , rsyslog / syslog-ng , etc), mas é possível *.cfg ter sido preferido quando caminhos de arquivo só podiam ter alguns caracteres . Provavelmente nunca mudou pela mesma razão /etc/fstab nunca foi renomeado, a maioria das pessoas que se importam já sabem o que o arquivo em questão faz.

    

Answer 2

Did something happen back in the day that divided the dev crowd into ... camps ...?

Você pode estar olhando a cronologia para trás. "De volta ao dia", o "Unix dev crowd" estava em todos os AT & T Bell Laboratories. (Se você fornecer energia suficiente para o capacitor de fluxo, você pode ser capaz de voltar a um tempo em que o "Unix dev crowd" era duas pessoas, e elas podem ter compartilhado um escritório, pelo que sei.) Mas então a Universidade da Califórnia (Berkeley) (e outras universidades menos conhecidas) começaram a modificá-lo, e empresas como IBM, Sun e Oracle entraram em ação (produzindo produtos como Xenix, AIX e Solaris), e isso não é nem mesmo contar todas as empresas (por exemplo, Sybase) que acabou de escrever software de aplicação para o Unix. (Veja O que exatamente é POSIX? para mais histórico / histórico em Unix / POSIX.)

Esses desenvolvedores (1) não sabiam o que os outros estavam fazendo, porque eles estavam trabalhando para organizações concorrentes, (2) achei que o caminho deles era melhor, e não se importou em dar ao usuário uma experiência uniforme, e / ou (3) deliberadamente optou por ser arbitrariamente incompatível, para fins de fragmentação do mercado. (Tem sido sugerido que a IBM fez estrategicamente o mercado Unix uma selva para afastar os clientes do Unix e de volta para seus sistemas operacionais proprietários.) Isso é apenas uma fração do legado do Linux.

Então, por que isso não foi "consertado"? Bem, como você mesmo disse: "Se não está quebrado, não conserte". E compatibilidade retroativa em produtos (por exemplo, mySQL) pode ser considerado mais valioso que a compatibilidade horizontal entre produtos.