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


34

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.


12
nenhuma falta. Windows não é Linux. Linux não é Windows.
Edmz 21/09/2014

27
@ Arsalan00 Está faltando um ponto importante. Geralmente, existe uma GUI para gerenciadores de pacotes (Ubuntu Software Center, Synaptic, YaST, etc.).
precisa saber é o seguinte

30
Eu nunca entendi um ponto desses assistentes, 99,99% dos usuários clicam cegamente em "Continuar" de qualquer maneira, portanto, uma instalação silenciosa e não interativa faz muito mais sentido.
SK-logic

7
@DebugErr Você está ofendido por uma piada simples. Nenhuma ofensa foi intencional.
Michael Hampton

6
É um dos muitos sinais de que o Linux, em qualquer um de seus sabores atuais, é destinado apenas a servidores e outros ambientes especializados, não ao uso do consumidor. As pessoas normais estão completamente sobrecarregadas, mesmo por apt-get ou "centros de software" desconhecidos. Você deve fornecer a essas pessoas um .exe para clicar, não um .tar.gz ou guias longos de página sobre como fazer com que o software básico funcione. Lamento incomodar alguém com a minha opinião.
Traubenfuchs

Respostas:


63

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.


15
+1 ... "cada instalação de pacote tem o mesmo processo."
Uwe Plonus

7
Bem, os desenvolvedores precisam se preocupar em criar um pacote adequado para cada distribuição que desejam oferecer suporte, de modo que precisarão de um ou mais RPMs, debs, scripts de criação de portas diferentes etc. Os gerenciadores de pacotes são ótimos, mas tentam oferecer suporte. todos os sistemas como desenvolvedor são difíceis. É por isso que a maioria das pessoas que mantêm pacotes para distribuições não são realmente os desenvolvedores upstream.
Alan Shutko

12
Uma desvantagem séria dessa abordagem é que os pacotes estão (em alguns casos seriamente) desatualizados. No Windows, posso instalar a versão mais recente sempre que possível; no Linux, tenho que usar (instalar e entender!) um cliente de controle de versão para obter a fonte e diferentes compiladores ou Make / CMake / etc. para construí-lo.
Marczellm 21/09

4
Muitos projetos que fornecem a última versão estável, sem a necessidade de controle de origem (a menos que você deseja que o mais recente desenvolvimento version ...). No entanto, você ainda precisará compilá-los, porque é impossível criar um binário que funcione imediatamente para todos os SOs do tipo * nix (ao contrário do Windows, que é uma plataforma muito estável e homogênea). Felizmente, os compiladores são muito fáceis de configurar e instalar no Linux, em comparação com o Windows.
Rufflewind

3
@ API-Beast responde completamente à pergunta. Os desenvolvedores não precisam criar assistentes; essa tarefa complicada é realizada pelas distribuições.
Florian Margaine 22/09

42

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.


6
No entanto, a maioria das pessoas não-tecnológicas que eu conheço preferiria baixar um instalador e executar o assistente em vez de abrir um terminal e digitar um comando. Essa coisa de gerenciador de pacotes é ótima para nós, geeks, mas realmente incomoda um usuário comum de PC que começou a usar PCs após a era do Windows 98.
Arsalan Ahmad

43
@ Arsalan00 Pense no modelo Linux como AppStore - é realmente o mesmo modelo. Você pode perguntar por que não existem assistentes para Android ou iOS.
Maciej Piechotka

5
Android e iOS são muito mais restritivos na maneira como operam e na maneira como permitem que os aplicativos funcionem. Linux é o oposto disso. Os SOs móveis aplicam convenções, o Windows parece recomendar convenções (pasta de arquivos de programas, registro etc.), enquanto o Linux é mais configuração do que convenção.
Arsalan Ahmad

9
Se o Windows não possui um "sistema de gerenciamento de pacotes de trabalho", o que é o Windows Installer ? Eu nunca ouvi falar de desenvolvedores que precisam reimplementar isso, pelo menos não nos últimos 10 a 15 anos.
Aaronaught

5
@Aaronaught E eu perdi a conta do número de programas do Windows que não usam o Windows Installer ou algo baseado nele e, portanto, são desnecessariamente difíceis para o gerenciamento de TI.
Michael Hampton

22

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.


14

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.


3
user-friendly é um termo subjetivo. Na IMO, a maioria dos usuários de computador reluta em usar ferramentas de linha de comando e acharia mais fácil e mais confortável se eles pudessem usar apenas um assistente. Mesmo que demore mais tempo.
Arsalan Ahmad

11
dpkge APT são usados ​​no Debian e no Ubuntu. apt-get, apt-cacheE aptitudesão invólucros em cima dpkg. dpkgraramente é usado diretamente, um caso de uso em que consigo pensar é instalar um pacote a partir de um .debarquivo.
usar o seguinte código

16
@ Arsalan00 geralmente existe uma interface gráfica de usuário para gerenciadores de pacotes, como o Ubuntu Software Center ou o yumex. Gerenciador de pacotes! = Terminal.
Florian Margaine

@ Arsalan00, se você usa o Ubuntu, basta ir para opera.com/download/guide/?os=linux , baixar o Opera para Ubuntu e clicar duas vezes no arquivo baixado. Não há nenhum terminal envolvido.
Oliver

13

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


Essa é uma ótima resposta e explica o problema do ponto de vista do usuário casual.
Arsalan Ahmad

11
"Os formatos dos pacotes não são padronizados entre plataformas." - Todas as distros compatíveis com LSB (que são a maioria das principais) suportam o formato de pacote LSB, que é um subconjunto de RPM com todos os recursos removidos que não podem ser facilmente mapeados para DEB. As ferramentas de linha de comando, APIs e ABIs para LSB RPM também são padronizadas.
Jörg W Mittag 22/09

@ Jörg W Mittag Eu dificilmente chamaria a conformidade com LSB padronizada. No Debian, "conformidade com LSB" está usando a ferramenta Alien que mencionei no meu post (e é limitada). E, novamente, não estamos comparando scripts de instalação a pacotes. Ele está comparando assistentes de instalação (que permitem que até o usuário mais casual instale software sem nunca ver a temida caixa preta) com os gerenciadores de pacotes. Exigir o uso de uma ferramenta como a Alien não está fornecendo o mesmo processo que um assistente de instalação.
Selali Adobor 22/09

@AssortedTrailmix: o formato do pacote LSB foi deliberadamente projetado para ser processado pelo Alien. E o usuário final nunca precisa interagir com o Alien, o gerenciador de pacotes LSB no Debian cuida disso. Além disso, os assistentes de instalação do edifício são explicitamente tratados no LSB. Se o assistente do instalador vincular apenas às bibliotecas LSB, ele poderá ser executado em todos os sistemas LSB e poderá chamar o gerenciador de pacotes LSB, porque isso é padronizado, e ele pode instalar um pacote, porque isso é padronizado, e no final você terminará com um DEB no banco de dados DPKG no Debian e um RPM no SuSE.
Jörg W Mittag

Entendo isso, mas acho que não entendi seu ponto de vista. Você não está apenas confirmando o que eu disse? Meu argumento era que um assistente de instalação e um gerenciador de pacotes não são os mesmos. Eu não estava sugerindo que um instalador não possa usar um gerenciador de pacotes. Parece que você concorda com a minha opinião, mas se depara com a pergunta retórica "Por exemplo, seu assistente incluiria vários formatos de pacotes para instalar?"
Selali Adobor 22/09

9

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.

5
+1 "Ter 20 programas atualizados separadamente no Windows é perturbador e ineficiente."
IQAndreas

Eu diria que chamar diálogos perturbadores ou ineficientes é um pouco demais. Se um programa tem um sistema de atualização mal projetado que prejudica os usuários assim que eles se conectam e não oferece uma opção de atualizações silenciosas, a culpa é do programa. Dito isto, não encontro muitos programas fazendo isso (a maioria deles são programas que não possuem um procedimento de inicialização tradicional), e o resultado final é sem dúvida mais gerenciável do que um prompt listando tudo o que é necessário ser atualizado.
Selali Adobor

E "repositório único e confiável" é um pouco enganador. É realmente apenas parcialmente aplicável se você estiver escrevendo um software que pode acabar por aí. O software proprietário não acaba facilmente nos repositórios padrão com suporte para distribuições comuns do Linux. Mesmo o repositório para parceiros canônicos no Ubuntu (cuja entrada é não trivial) é desabilitado por padrão e considerado inseguro por muitos, já que os riscos à segurança do software hospedado lá são conhecidos por ficarem sem patch por muito mais tempo que o mesmo software baseado em outros métodos de atualização.
Selali Adobor 22/09

6

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.


11
Esse é um problema fácil de resolver. Muitos instaladores do Windows têm uma opção silenciosa e são preenchidos com bons padrões, para que o usuário não precise fazer nada além de pressionar os botões a seguir.
Arsalan Ahmad

5
Eu odeio pressionar o próximo apenas porque os desenvolvedores falharam em fazê-lo de uma maneira mais simples.
Silviu Burcea

@ Arsalan00: o "usuário não precisa fazer nada além de ..." quebra a automação. Se o usuário precisar fazer algo , ele não poderá ser automatizado. Idealmente, você deve poder ligar uma máquina e deixá-la inicializar através do PXE, instalar um sistema operacional e, em seguida, instalar e configurar tudo o que você precisa, sem a interação do usuário. Com o Linux, você pode fazer isso (exceto talvez alguns aplicativos, mas ainda não encontrei nenhum).
Arseni Mourzenko

11
@MaMaMa sua edição realmente bate na unha. Se os desenvolvedores quiserem, eles podem tornar seus instaladores programáveis ​​ou silenciosos. Mas o sistema do assistente realmente ajuda o usuário iniciante a apresentar o que é a configuração, e os assistentes informam o usuário como os gerentes de pacotes não podem. Além disso, as instalações offline são algo que é uma necessidade importante para muitas pessoas.
Arsalan Ahmad

2
@ Arsalan00 geralmente os gerenciadores de pacotes podem fazer perguntas se realmente precisarem. As instalações offline são possíveis com os gerenciadores de pacotes, basta baixar o pacote primeiro, assim como você faz ao baixar e instalar o arquivo. E, por último, é mais amigável, a maioria dos usuários iniciantes não deve se preocupar com "onde você deseja instalar isso" etc. etc. deve "apenas funcionar".
iveqy

-1

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.


4
Um assistente de instalação permite personalizar mais do que um gerenciador de pacotes que geralmente é usado no linux.
iveqy

@iveqy Qualquer arquivo de configuração de texto oferece muito mais habilidades do que qualquer "assistente" de instalação. Se esses bruxos pudessem fazer melhor, eles existiriam, mas não o fazem.
Rob

4
isso é verdade, mas editar arquivos de configuração de texto não faz parte do processo de instalação da maioria dos gerenciadores de pacotes. Normalmente, as perguntas em um processo de instalação do Windows são "onde você deseja colocar isso", um gerenciador de pacotes já decide isso no ambiente linux e "quais componentes deste programa você deseja instalar" e que já foi decidido por o mantenedor do pacote no caso de gerenciadores de pacotes. Você pode ver que um gerenciador de pacotes é mais amigável, pois é usado para android e iphone (loja de aplicativos e google play).
iveqy

@iveqy Acabei de perceber que saímos do tópico. Isso não tem nada a ver com o que eu disse originalmente e que você ainda não vê esses assistentes, é mais uma evidência do que eu disse.
Rob
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.