Heurística para fazer uso ou dispensar documentação antiga [fechada]

Question

Obtendo-os como resultados de pesquisa ou seguindo links de referência, muitas vezes me deparo com documentação produzida há algum tempo. Alguns meses, alguns anos. Às vezes, os documentos são marcados como reprovados ou inoportunos, mas nem sempre.

Mas mesmo se histórico, até que ponto eles ainda são aplicáveis. É possível desenhar um mapa geral da dinâmica de mudança dos campos * nix? Qual a probabilidade de certas áreas terem mudado (ou mudado no futuro), quanto e com que frequência?

Esta questão é semelhante a Quão atualizado e relevante é "The Linux Documentation Project"? , mas é mais geral. Estou pedindo linhas básicas como:

(estes são apenas exemplos sem se ligar à realidade)

• "A estrutura principal do sistema de arquivos não mudou por 25 anos e não será alterada para os próximos 25, como é garantido pelo POSIX, porque isso tornaria o mundo * nix de cabeça para baixo. Você pode confiar na documentação até 25 anos de idade. "

• "A API das bibliotecas C muda a cada poucos meses, especialmente na área de redes, já que há um grande número de funções básicas, que são consideradas padrão, mantidas inalteradas desde , e nunca vai mudar, porque isso é reinvenção da roda. "

Indiretamente, essa pergunta também pergunta em que medida as dicas em sites de perguntas e respostas como essa permanecem válidas com o passar do tempo.

    

Answer 1

As duas citações que você postou soam como a opinião de alguém, não como "documentação".

Padrões são alvos móveis. Pode-se procurar implementá-las, mas a cada poucos anos elas são atualizadas, e sempre haverá extensões e instâncias onde um padrão não é propositalmente seguido. Isso vale para "padrões apropriados", bem como para "padrões ad hoc".

Padrões como o POSIX, porém, mudam apenas lentamente ao longo do tempo, com coisas novas sendo introduzidas conforme são úteis, demandadas e amplamente aceitas, e coisas antigas sendo descartadas à medida que são encontradas É por isso que alguns aqui na U & L estão empenhados em salientar que algumas coisas de shell (por exemplo) não são compatíveis com POSIX, mas só funciona (ou não, conforme o caso) com certas versões de certas implementações das ferramentas. É uma maneira de fazer uma resposta viver mais do que uma implementação específica oferecida pelo GNU ou algum outro fornecedor.

O melhor local para procurar documentação sobre as interfaces e ferramentas no seu sistema será sempre os manuais on-line no seu sistema , bem como qualquer outra forma de documentação possivelmente distribuída com o software você está usando.

Você pode pesquisar na Web o que um determinado flag para os utilitários sed ou grep faz, ou como usar Getopt::Long em Perl, mas será o manual instalado com o utilitário ou biblioteca real no seu sistema que é a documentação definitiva.

A documentação histórica é útil para pessoas que executam os mesmos sistemas antigos, não há nada que a negue, mas uma documentação é normalmente destinada a um sistema ou ferramenta como se estivesse no momento da escrita. Se você está em um novo sistema OpenBSD 5.9, por exemplo, e quer saber porque sudo não funciona, porque você está lendo uma página web dizendo que ela deveria estar no sistema básico, bem, teria sido melhor se você leu o manual afterboot(8) (conforme solicitado) que descreve o sistema que você acabou de instalar . Isso informará sobre o utilitário doas .

Meu ponto é, não importa onde o Unix está indo ou se está vindo. Você está na frente de uma máquina que está rodando agora , e onde você encontrará a documentação mais atualizada.

Se você vir algo na web descrevendo como configurar o UUCP para trocar e-mails entre hosts, ou como fazer replicação de banco de dados no PostgreSQL, você deve levar em consideração o público-alvo do documento e que essas ferramentas podem ser e se comportar de maneira diferente para você, devido ao tempo. Os manuais em seu sistema tem você , o usuário querendo saber como usar o sistema que está à sua frente, como o público pretendido.

Me desculpe se eu perdi um pouco a marca com a minha resposta, mas é algo que eu tenho pensado um pouco ultimamente.

    

Answer 2

Eu diria que não, você não pode a priori desenhar um mapa para navegar com segurança.

Você mencionou sites de perguntas e respostas. Os fóruns do IME Q & A são muitas vezes terríveis para isso. Você recebe um punhado de opiniões, mas não explicações totalmente fundamentadas. A "documentação" de terceiros, disponibilizada por pesquisas na Web, como os posts de pessoas, costumam ter uma qualidade semelhante. Concedido as respostas são úteis no momento; eles permitem que você veja as experiências e leituras que outras pessoas têm. Mas uma explicação fundamentada, com referência às fontes primárias, pode ser educacional mesmo quando está completamente obsoleta.

Desde que você pergunta. Eu diria que POSIX é sobre isso. Vários fornecedores padronizaram 1) chamadas de sistema e 2) comandos de utilitários, e estes permanecerão funcionais no futuro para preservar a compatibilidade com aplicativos existentes.

Novamente, lembre-se de que a autoridade é o próprio padrão. Meu curso de ciências da computação em uma universidade altamente classificada combinou o padrão de threads POSIX com a tentativa inicial inconsistente do Linux de implementá-lo. Ignorando o contraexemplo da segunda implementação (NPTL). E o material desses cursos é frequentemente disponibilizado on-line ...

O problema é que, uma vez que tenha sido acordado e consagrado no padrão, ele não permanece necessariamente relevante e interes- sante. Eu sinto que a falha do Linux Standard Base seria um exemplo disso. (Observe que os esforços recentemente comparáveis, como os aplicativos xdg flatpack, são construídos em relação aos tempos de execução versionados . E observe a rapidez com que o GTK está sendo alterado).

Acho que olhar para a segurança fornece exemplos strongs. Nós ainda não descobrimos como construir um sistema seguro ainda. Sistemas que são antigos / não corrigidos / não tiveram mitigações aplicadas para o bug du jour são considerados completamente quebrados. Então eles mudam constantemente.

Advertência ao amor POSIX: os sistemas operacionais usados no mundo real serão desviados do padrão de alguma forma. OS X, com certificação POSIX - fsync() de implementação foi banida de fazer o que todo mundo considera o significado pretendido. Certos greybeards do Linux argumentam que devemos quebrar aplicativos que usam nomes de arquivos irritantes, por exemplo. que incluem caracteres de controle. Etc.