Eu sempre me perguntei, e a outras pessoas, essa pergunta, e gostaria de abordar um ponto que muitas vezes vejo antes de entender por que o Linux vê menos instaladores:
As distribuições Linux fornecem gerenciadores de pacotes.
No entanto, eu não diria que o gerenciador de pacotes de uma distribuição Linux é um substituto para um instalador, em parte pelos seguintes motivos:
Esses gerenciadores de pacotes não são padronizados em operação
Um gerenciador de pacotes é um pouco como fornecer seu binário e permitir que o usuário final escolha o instalador. Eles podem escolher o terminal ou podem escolher uma ferramenta com uma GUI mais avançada, mas não oferece o mesmo controle de nível do processo que um assistente de instalação "tradicional".
Um exemplo do que quero dizer com controle é documentação. Você não pode dar instruções ao usuário final como "Clique em Avançar e você deverá ver". Você pode dar instruções na linha de comando para uma ferramenta específica, mas não depende apenas do fato de o usuário ter essa ferramenta, mas também perde a maioria dos benefícios de um assistente de instalação (afinal, a maioria dos assistentes está fornecendo uma interface -end para instruções simples da linha de comando e scripts de lançamento).
Isso também se vincula à estética. Agora você depende da sua distribuição de usuários finais para fornecer uma interface intuitiva / apropriada. Enquanto você está totalmente ciente desse fato, não é irracional para um usuário mais casual reclamar se clicar duas vezes no seu arquivo (o instalador, na visão deles) abre um feio gerenciador de pacotes, não faz nada, ou o pior de tudo, abre um terminal janela. (As experiências que tive com os usuários e sua aversão ao "dos prompt" / "caixa preto e branco" / "O que excluirá todos os arquivos se parecer engraçado" provavelmente pode encher um livro)
Os formatos de pacote não são padronizados entre plataformas.
Existem ferramentas para converter entre sistemas como rpme deb, mas não é razoável esperar que o usuário final converta seus pacotes se você os estiver usando em uma situação em que um assistente de instalação seria fornecido em outra plataforma (ou seja, clique e pronto) ) Fornecer pacotes atualizados para um formato de pacote adicional pode ser bastante simples se você tiver um sistema de compilação rudimentar, mas ainda assim estiver adicionando um novo binário que precisa ser suportado.
Isso também adiciona um novo binário que as pessoas precisam escolher, dependendo da plataforma (parece menor, mas tenho certeza de que alguém aqui pode atestar a necessidade de explicar x86 x x64 antes [sim, existem maneiras de deduzir a plataforma correta do navegador, mas você está se envolvendo em procedimentos ainda mais complicados e difíceis de suportar])
Os gerenciadores de pacotes são "mais agradáveis" para o software de código aberto.
Isso não está dizendo que você não pode compartilhar software de código fechado com um sistema de gerenciamento de pacotes; isso definitivamente pode ser feito. Mas uma vez que você tenta compartilhar software de código-fonte próximo nas distribuições Linux, você se depara com uma barreira no que diz respeito às suas opções para colocar seu software em repositórios comuns. Coisas como PPAs ou o openSUSE Build Service estão disponíveis, e mesmo os repositórios Canonical Partners não estão ativados por padrão.
Isso significa que, a menos que você forneça seu próprio repositório, não poderá obter muitos dos principais recursos dos sistemas de gerenciamento de pacotes, incluindo atualizações automáticas. Na minha opinião , esse é o benefício mais importante na maioria das plataformas que usam esses sistemas (por exemplo, iOS, Android e Windows Store).
E mesmo que você forneça um repositório (outro trabalho de trivialidade variável), ainda será necessário que os usuários o configurem (que é outra camada de suporte, outro conjunto de abordagens não padrão e outro desvio do ponto original do instalador)
Agora, tendo dito tudo isso, ainda não resolvi o problema original, por que os instaladores são menos comuns no Linux, apesar desses fatores (entre outros). A pergunta original pergunta se é técnica ou se é baseada em convenções, e se baseia em ambas, em parte.
Se você observar os fatores acima mencionados, eles também tornam as coisas mais complexas para um instalador "parecido com um assistente". Por exemplo, seu assistente incluiria vários formatos de pacote para instalar? Como você lida com a aparência entre distribuições? A lista continua, e uma coisa que se os pacotes não permitir-lhe é que nada disso vai ser sua preocupação ( para melhor ou para pior ), contanto que você fornecer os pacotes corretamente. E, dependendo da natureza do seu projeto, você pode começar a tirar proveito desses recursos mais "especializados", como o envio de aplicativos ao Ubuntu Software Center. Tudo isso se relacionaria com o técnico.
Mas o aspecto que pessoalmente considero a força motriz é a convenção. (Espero ter enterrado tão fundo o suficiente para que as pessoas que votaram contra essa outra resposta ao esquecimento parem de ler ..)
Eu acho que o pôster tinha um ponto, mas poderia tê-lo dito sem rodeios, e na verdade não forneceu razões objetivas para esse ponto. Se você examinar as diferenças que afirmei para um gerenciador de pacotes e um instalador, não ficaria surpreso se você descobrisse que a maioria delas é quase um problema (talvez até mesmo um pedante). Mas (desculpe o que eu espero que seja visto como uso legítimo de um argumento ad hominem) também somos usuários no local para programadores. Eu vejo distribuições Linux empurradas como uma excelente alternativa do Windows para usuários casuais (entre muitas outras coisas, obviamente). Não fornecer um procedimento de cliques-e-feito comumente definida que todos esses usuários podem usar realmente não é ideal imo .
Mas, ao mesmo tempo, também não acho que muitas coisas no Linux sejam ideais para esse grupo. Certamente, algumas distros têm gerenciadores de pacotes baseados em GUI, mas isso significa que essas pessoas precisam começar a estudar como usar uma ferramenta separada, que não é estritamente focada na instalação do seu programa (compare isso e isso com isso ).
Naturalmente, você pode usar a GUI para obter a maioria que seu usuário casual médio precisa fazer, especialmente em determinadas distribuições (ironicamente, as coisas que essas distribuições estão fazendo nem sempre são adotadas na comunidade de código aberto). garden "]) Mas não acho que seja negável que as convenções do Linux favoreçam alguém que se sinta confortável com uma CLI ou, pelo menos, que não tenha muito medo de sua aparência, significa que eles fizeram algo terrivelmente errado.
Não estou dizendo que é para isso que eles almejam, mas é realmente o que vejo essas convenções fazerem. E os sistemas de gerenciamento de pacotes no Linux parecem estar seguindo isso. Afinal, a maioria de suas "desvantagens" quase não existe se o usuário final se sentir mais confortável com os conceitos subjacentes.
Os instaladores na maioria das outras plataformas não são realmente afetados por isso, e são projetados para, para citar um comentário sobre a pergunta, "99,99% dos usuários [podem] clicar cegamente em" Continuar ". O problema com o gerenciamento de pacotes é levar esses usuários a um botão "Continuar", informando o que é esse botão "Continuar" (vi usuários sendo atropelados por ferramentas que disseram pressionar enter com outro texto) e informando quando chegarem a esse ponto "ao clicar o estágio "Continuar" botão ".