O que Linus Torvalds quis dizer com sua citação sobre portabilidade? [fechadas]

Em um debate com Andrew Tanenbaum sobre a arquitetura do sistema operacional microkernel vs. monolítico, Linus Torvalds disse:

Portabilidade é para pessoas que não podem escrever novos programas.

O que ele quis dizer com isso?

Como Linus escreve no debate, é com a língua na bochecha (ou seja, não deve ser levado muito a sério).

Depois, ele continua explicando que, embora a portabilidade seja boa, também é uma troca; código não transportável pode ser muito mais simples. Ou seja, em vez de tornar o código perfeitamente portátil, basta torná-lo simples e portátil o suficiente ("aderir a uma API portátil") e, se precisar ser portado, reescreva-o conforme necessário. Tornar o código perfeitamente portátil também pode ser visto como uma forma de otimização prematura - geralmente mais mal do que bem.

Claro que isso não é possível se você não puder escrever novos programas e precisar ficar com o original :)

Eu acho que isso significa que cada programa deve ser escrito especificamente para o hardware e sistema operacional em que é executado.

Acho que o que ele está dirigindo é que o código de uso geral que pode ser executado em várias plataformas é menos eficiente ou mais suscetível a erros do que o código escrito especificamente para e adaptado a uma plataforma. Entretanto, isso significa que, quando você se desenvolve dessa maneira, precisa manter várias linhas de código diferentes.

Quando o Linux foi escrito pela primeira vez, ele usava recursos disponíveis apenas na CPU i386, que era relativamente nova e cara na época.

É exatamente isso que o linux faz: ele usa apenas um subconjunto maior de recursos do que os outros kernels parecem fazer. Obviamente, isso torna o kernel propriamente portável, mas também cria um design / muito / mais simples. Uma troca aceitável e que tornou o linux possível em primeiro lugar.

Quando entramos no século 21, os recursos que tornaram o i386 exclusivo tornaram-se totalmente populares, permitindo que o Linux se tornasse muito portátil.

Como alguém que fez muito Java e experimentou o fenômeno "escreva uma vez, depure em todos os lugares" semanalmente durante anos, posso me relacionar totalmente com isso.

E Java é provavelmente um exemplo leve. Não consigo nem imaginar o que as pessoas passam e que tentam usar uma base de código portátil em um idioma / kit de ferramentas que nem foi projetado para ser portátil por si só.

Agora, no trabalho, estamos investigando a ideia de escrever uma versão simplificada de um de nossos produtos para dispositivos móveis. Eu fiz algumas pesquisas sobre como fazer uma versão portátil para J2ME e Android - que tenta compartilhar o máximo possível da base de código (obviamente não pode ser totalmente "portátil" por si só, mas é uma filosofia semelhante). ) É um pesadelo.

Então sim, às vezes é realmente bom pensar (e fazer) em termos de uso das ferramentas fornecidas para o trabalho em questão. ou seja, desenvolvendo-se livremente contra uma única plataforma / ambiente monolítico. E apenas escrevendo versões separadas e limpas para cada uma.

Embora algumas pessoas vejam / tratem a portabilidade, seguindo padrões etc., como moralmente superior, ou algo nessa ordem, o que realmente se resume a economia é.

A gravação de código portátil tem um custo em termos de esforço para tornar o código portátil e (frequentemente) precedendo alguns recursos que não estão disponíveis em todos os destinos.

O código não portátil tem um custo em termos de esforço para portar o código quando / se você se preocupa com uma nova arquitetura e (geralmente) renuncia a alguns recursos que não estão (ou não estavam) disponíveis no destino original.

O grande qualificador existe "quando / se você se preocupa com uma nova arquitetura". Escrever código portátil requer esforço antecipado, na esperança de uma eventual recompensa de poder usar esse código em arquiteturas novas / diferentes com pouco ou nenhum esforço. O código não portátil permite adiar esse investimento na transferência até que você tenha (pelo menos razoavelmente) certeza de que realmente precisa portar para algum destino específico.

Se você tem certeza inicial de que vai transportar para muitos alvos, geralmente vale a pena investir antecipadamente na minimização dos custos de transferência de longo prazo. Se você tiver menos certeza sobre quanto (ou mesmo se) precisará portar o código, a criação de códigos não portáteis permitirá minimizar o custo inicial, atrasando ou, possivelmente, evitando completamente o custo de tornar o código portátil.

Eu acho que também vale a pena notar que eu falei de "portátil" e "não portátil" como se houvesse uma divisão clara entre os dois. Na realidade, isso não é verdade - a portabilidade é um continuum, passando de totalmente não portátil (por exemplo, código de montagem) a extremamente portátil (por exemplo, Info-zip) e em todos os lugares.

Tanenbaum argumenta que grande parte do Linux é escrita de forma não modular para alavancar a CPU 386, estado da arte da época, em vez de tornar a interação da CPU um componente e, portanto, muito facilmente trocável. Tanenbaum acredita essencialmente que o fato de o Kernel ser tão monolítico e vinculado à CPU 386 torna muito difícil,

• Portar o próprio Linux para outra plataforma de CPU (obviamente incorreta, AMD64, PowerPC, etc)
• Programas de porta gravados para linux x86 em outra arquitetura de CPU (também incorreta)

O acampamento linux faz vários pontos, entre os quais:

• Linux oferece sistema de arquivos multithread como parte do design
• Microkernel, embora interessante e intuitivo, não tem muito desempenho
• A aderência à API portátil torna a questão da portabilidade mais ou mais pequena do que um bloqueador.

Se você deseja escrever um código portátil, você deve escrever um código portátil.

O que quero dizer com isso?

O design deve refletir o objetivo. Se o idioma for C, por exemplo, projete-o para que o número mínimo de linhas de código precise ser alterado para que ele funcione. Isso geralmente significa separar a exibição da computação, o que é uma boa filosofia de design (MVC). A maioria dos códigos C pode ser compilada em qualquer lugar, desde que você tenha acesso a um bom compilador. Aproveite isso e escreva o máximo que puder para ser genérico.

BTW, esta resposta se aplica apenas a aplicativos. OS e incorporado são outro animal inteiramente.

Interprete esta afirmação "literalmente" do jeito que está.

Em outra citação de Linus, ele disse: "O C ++ está tentando resolver todos os problemas errados. As coisas que o C ++ resolve são coisas triviais, extensões quase puramente sintáticas ao C, em vez de consertar um verdadeiro problema profundo".

Também em sua biografia, o "Just For Fun", enquanto citava microkernels, dizia que, para um problema com complexidade 'n', se você dividir o problema em partes únicas de '1 / n' ... então a complexidade total do desenvolvimento de um sistema desse tipo seria seja 'n!' isso por si só é um fator suficiente para não tentar tal coisa, e extrair eficiência de um sistema tão complexo seria muito difícil.

Você deve levar em conta o fato de que, durante esses debates, o Linux era muito novo e, em grande parte, era apenas um sistema operacional 386. Acho que se você perguntasse a Linus hoje, ele teria uma opinião diferente. Talvez não tão extremo quanto Tannenbaums, mas ele provavelmente acenará com a cabeça e dirá que estava certo sobre algumas coisas.

Linus e os outros desenvolvedores de kernel sofreram muito para tornar o Linux portátil, mas, novamente, o Linux talvez nunca existisse se Linus tivesse que fazê-lo portátil para começar.

Isso significa que as pessoas que podem escrever bons programas não precisam que as coisas sejam portáteis, porque podem trabalhar do zero.

São menos programadores talentosos que desejam "importar" outros programas (portabilidade) para o atual.