Por que os desenvolvedores não fazem assistentes de instalação no linux? [fechadas]

Tenho certeza de que não se trata de preguiça ou algo parecido, mas não entendo por que os desenvolvedores, mesmo principalmente de aplicativos voltados para o consumidor, não fazem nenhum tipo de assistente de instalação para onde você vai no próximo acabamento. Os mesmos aplicativos geralmente têm instaladores para Windows e Mac OS; por que não o Linux?

Existe alguma razão técnica para essa tendência ou é apenas uma convenção?

EDIT (23-09-2014): Esta pergunta não foi solicitada para iniciar uma guerra de chamas entre Windows e Linux. Eu usei os três principais sistemas operacionais e, além do Linux, os outros dois (Windows e Mac OS) possuem instaladores. Ainda não instalei o Oracle, mas, seja o que for necessário, nunca vi nenhum instalador de GUI para Linux.

Sim, eu sei que o Linux possui gerenciadores de pacotes para que os desenvolvedores não "precisem" de fazer os instaladores. Mas ainda há uma enorme quantidade de software desatualizado nos gerenciadores de pacotes padrão ou simplesmente não disponível. Além disso, como o Linux é vendido como uma alternativa ao Windows para usuários casuais (o Ubuntu está se esforçando nesse domínio), faria muito mais sentido apenas dar aos usuários o que eles estão familiarizados.

Tomemos, por exemplo, a configuração de uma pilha LAMP. Todos esses são softwares de código aberto nos repositórios padrão, mas você pode configurar tudo de uma só vez sem um script? Agora olhe para o servidor WAMP no Windows. Você acabou de executar um instalador e ele instala vários softwares de forma que eles funcionem bem um com o outro. Em seguida, ele define bons padrões e outras coisas. Os instaladores podem fazer isso, os gerenciadores de pacotes não. Sim, você pode encontrar um script para isso online, mas onde? E qual?

Os instaladores não são uma tecnologia obsoleta do passado. Eles ainda são úteis e 95% dos usuários já estão confortáveis ​​com eles.

Os desenvolvedores precisam apenas fornecer um pacote para uma distribuição. Cada distribuição tem uma maneira de instalar este pacote. Desta forma, pode ser em um terminal ( apt-get) ou através de uma interface gráfica, por exemplo, Ubuntu Software Center.

O bom é que os desenvolvedores precisam se preocupar em criar um pacote adequado; os fabricantes de distribuição cuidam do resto e cada instalação de pacote tem o mesmo processo.

Porque eles não precisam. As distribuições Linux geralmente têm sistemas de gerenciamento de pacotes em funcionamento, diferentemente do Windows, onde cada aplicativo precisa reimplementar a instalação e a atualização repetidas vezes.

A maioria de código fechado, como-em-cerveja grátis software não for Linux não vêm com assistentes de instalação. O mesmo acontece com alguns softwares de código-fonte, gratuitos como cerveja, pelo menos até que a maioria das grandes distribuições o compreenda. Para software de código aberto, os gerenciadores de pacotes são uma solução claramente superior.

Então, e os estágios iniciais antes que o software de código aberto seja escolhido pelas principais distribuições? Por que os desenvolvedores não criam assistentes de instalação durante essa fase?

Primeiro de tudo, muitos desenvolvedores de código aberto não se importam com a distribuição. Eles escrevem um software para uso próprio e o divulgam caso seja útil para outras pessoas, mas consideram o empacotamento para distribuição o problema de outra pessoa. Se for apreciado o suficiente, alguém assumirá a tarefa de colocá-lo em sua distribuição favorita.

Os desenvolvedores de código aberto que fazer se preocupam com distribuição ainda melhor para trabalhar dentro do sistema gerenciador de pacotes são, porque é onde seus clientes estão. Os usuários do Linux normalmente não pesquisam na web procurando por software. Eles pesquisam seu gerenciador de pacotes primeiro. Na falta disso, eles pesquisam os repositórios "mantidos pela comunidade", como os PPAs do Ubuntu ou o AUR do Arch. Se você não estiver nesses lugares, é provável que seu software não seja notado e, se for notado, é menos provável que seja confiável.

A precedência desses canais de distribuição existentes é como decidir que os anúncios de superbowl são muito caros, então você vai sediar seu próprio campeonato de futebol e anunciar lá. Pode ser menos caro, mas também é menos eficaz.

No que diz respeito à personalização da configuração, para software como um servidor da Web que é tradicionalmente mais fácil de manusear com um arquivo de configuração, o que facilita o compartilhamento, o backup e a restauração da configuração.

Para software cliente como um navegador da Web, é muito melhor criar um assistente de configuração que apareça na primeira vez em que um novo usuário executa o software, em vez de fazê-lo no momento da instalação. O principal motivo é que o Linux é um sistema operacional multiusuário, portanto, você deseja personalizá-lo por usuário de qualquer maneira. Isso também facilita a execução do assistente de configuração mais tarde, por qualquer motivo, sem a necessidade de manter o programa de instalação por perto para reinstalar o software inteiro. Esse tipo de assistente é bastante comum no software Linux.

As distribuições Linux (também, acho, como Unices com sabor BSD) têm uma interface amigável para programar a instalação, por meio dos chamados gerenciadores de pacotes (ou gerenciamento de portas no caso BSD): pacman for Arch, dpkg para Debian / Ubuntu , e assim por diante.

Esses gerenciadores de pacotes fornecem uma maneira de instalar programas por meio de arquivos de configuração uniformes. Uma vez que o programa que você precisa é empacotado de acordo com o gerenciador de pacotes da sua distribuição, você pode simplesmente executar o comando de instalação no pacote selecionado (com personalizações ocasionais específicas do usuário, embora muitas vezes nenhuma) e o gerente faz o resto.

Os gerenciadores de pacotes geralmente são mais fáceis de usar do que os processos instaladores específicos do programa do Windows, apenas pela maneira uniforme como os programas são empacotados para instalação. Eles geralmente também permitem que você consulte o banco de dados do gerenciador de pacotes para o programa que está procurando, veja suas dependências.
Eles também oferecem suporte à atualização centralizada dos pacotes.

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 ".

Para grandes extensões são os dois. O modelo de distribuição Linux está mais próximo da AppStore / Play Store do que o tradicional Windows / Mac OS X one - e até essas plataformas estão se movendo para lá do que ouvi.

A convenção é que é mais simples. A maioria dos argumentos para a AppStore / Play Store também se aplica ao Linux:

• Atualizações automáticas. Ter 20 programas atualizados separadamente no Windows é perturbador e ineficiente. O usuário precisa clicar nas atualizações Java / Flash / Adobe / ... na inicialização.
• Repositório único e confiável. Você verifica se faz o download via conexão segura? Ou você não fez o download de uma atualização do Reader em get.adobe.com.hackers.example.com/setup.exe? Mesmo se você faça a maioria dos usuários, especialmente os usuários avançados, não . Em vez disso, você vai ao centro de software ou programa similar no Linux e obtém uma cópia confiável.

Além disso, existem os seguintes benefícios, que podem não se aplicar à AppStore / Play Store:

• Nem todo Linux tem GUI - pense em servidor http -, mas a maioria das distribuições suporta essa configuração. Está bem. Nem todo mundo precisa de um, mas mais cedo ou mais tarde alguém vai querer usá-lo por qualquer motivo.
• As ABIs de bibliotecas em várias distros podem ser diferentes. Não entrar em detalhes com um instalador colocaria a responsabilidade do programa trabalhando em você, em vez de manter um pacote no repositório.
• Conectado com o anterior - você precisa gerenciar dependências de alguma forma. O empacotamento é considerado impróprio por um motivo - nesse caso, você precisa garantir que você atualizou a biblioteca para a versão sem erros - por exemplo, você não incluiu o openssl 1.0.1f em seu pacote. A prática mostra que as pessoas incluem bibliotecas desatualizadas com vulnerabilidades de segurança conhecidas.

Geralmente, a instalação não precisa de interação com um usuário (a maioria apt-get pacotes, por exemplo) ou pode ser script. Isso facilita muito a automação para implantar um software em muitas máquinas. Em vez de fazer as coisas através do assistente, você faz as mesmas coisas por meio de scripts ou de arquivos de configuração.

Dado que no mundo Linux, o terminal vem em primeiro lugar, e a GUI é opcional, torna-se óbvio por que eles não possuem assistentes de instalação reais.

O Windows, por outro lado, é muito orientado ao usuário. A maioria dos arquivos MSI pode ser implantada facilmente de maneira autônoma, da mesma forma que a instalação do Windows pode ser autônoma (a facilidade / dificuldade de fazer o WAIK funcionar é um assunto diferente). Isso também significa que vários aplicativos para Windows não são baseados no MSI e não podem ser executados por script. Entre os aplicativos em escala corporativa, os produtos Adobe, por exemplo, são conhecidos por serem bastante difíceis de instalar de maneira com script.

O público-alvo é diferente. Os sistemas Unix e Unix-like eram geralmente usados ​​por programadores profissionais, administradores de sistemas, engenheiros e entusiastas sérios que personalizavam cada sistema de acordo com suas necessidades. Qualquer "assistente de instalação" limitaria apenas suas opções em vez de dar acesso a todas as variáveis ​​necessárias. E os que estão por aí ainda o fazem.

O Windows não é voltado para profissionais da mesma maneira e, portanto, possui instaladores de uso mais geral voltados para "usuários" que desejam apenas a instalação. O Linux está recebendo mais desses tipos de usuários que provavelmente apreciariam isso, mas, possivelmente, a maioria das distros ainda tem o profissional em mente.