Seria possível o Linux possuir um sistema de instalação/desinstalação de aplicativos igual do Mac OS

Thihup
(usa Manjaro Linux)

Enviado em 14/02/2016 - 18:45h

Olá!

Minha pergunta não está muito clara, mas o que eu quero dizer é, será que existe alguma forma de criar um aplicativo que seja possível instalar/desinstalar aplicativos de forma semelhante ao Mac OS? Estava olhando e usar o Drag 'n drop é muito bacana. Eu estava elaborando uma forma de criar algo do gênero para os aplicativos .deb e acho que seria muito bacana, sem falar que a usabilidade também seria um pouco melhor [é claro, sem querer menosprezar os outros aplicativos, como a central de programas do ubuntu, por exemplo]. E aí, o que vocês acham?

Abs

Thiago

removido
(usa Nenhuma)

Enviado em 14/02/2016 - 19:00h

Teria que criar um sistema de pacotes diferente. Os aplicativos do OSX nada mais são que pastas com a terminação .app (ou .application, não me lembro agora), que são instalados (arrastados) em /Applications. Nesse caso, é até óbvio o conceito de arrastar a pasta/aplicativo para a lixeira para desinstalá-lo/removê-lo. Tudo que pertence ao aplicativo (bibliotecas, executáveis) é incluso nesta pasta, nada de separar arquivos em /usr, /etc, como é no Linux.

Acredito que no Linux daria pra fazer algo parecido, o problema são as bibliotecas. No OSX, assim como o Windows, as bibliotecas são incluídas no aplicativo (mais especificadamente dentro da pasta .app).

Thihup
(usa Manjaro Linux)

Enviado em 14/02/2016 - 19:12h

Bom, então precisaria criar um novo sistema de pacotes, e que dentro dele fossem incluido as bibliotecas dinâmicas, hum, acho que estou pegando o "espírito" da coisa. Seria algo como o Teamviewer para "distribuições não suportadas oficialmente", que é só abrir o executável.

Então seria algo bacana de se implementar, mas para isso seria necessário uma nova distro. Mas acho que a ideia é bom, não é? Só que se eu fizesse em casa sozinho seria loucura. Daria talvez até como implementar um sistema para "instalar oficialmente" no sistema, e não só ser um aplicativo "off system".

Vou estudar e ver se consigo fazer algo bacana. Mas seria o máximo criar algo do tipo.

[]'s

T+

--

Att,

Thiago Henrique Hüpner

(Mensagem scaneada pelo antivírus........ops! não precisa, afinal eu uso Linux!)

removido
(usa Nenhuma)

Enviado em 14/02/2016 - 19:21h

Eu particularmente prefiro este modelo de pacotes. É mais prático para o usuário, e elimina a inconsistência de pacotes.

Thihup
(usa Manjaro Linux)

Enviado em 14/02/2016 - 19:22h

Do Linux ou do Mac?

[]'s

T+

--

Att,

Thiago Henrique Hüpner

(Mensagem scaneada pelo antivírus........ops! não precisa, afinal eu uso Linux!)

removido
(usa Nenhuma)

Enviado em 14/02/2016 - 19:23h

Mac.

shoujo
(usa Slackware)

Enviado em 14/02/2016 - 19:37h

O problema disso é que os softwares ficariam muito grandes.
Você poderia embutir as dependências de um software nele, por exemplo mas como os programas para Linux estão acostumados com a estrutura /usr /bin /etc etc, seria meio complicado, no caso você teria que criar uma distro com pacotes padrão, bem básica, para saber quais dependências vc não precisa incluir nos softwares, criar uma pasta especial onde os softwares são instalados, e criar um jeito de incluir os /bin no patch do Linux, alem das /lib, talvez vc tenha que linkar as pastas pode dar certo criar links simbólicos xD
Por exemplo vlu te dar uma ideia não sei se vai funcionar.
O pacote do vlc, você vai instalar ele faz o seguinte:
mkdir -p /applicativos/vlc/
ln -s /usr/bin /applicativos/vlc/bin

Fazer o mesmo com as outras pastas importantes lib share etc..
Ai voce pode instalar normal na /usr/bin e tais que os aplicativos irao ficar corretos..
Quanto as dependências, voce teria que criar um sistema igual o .deb ou .rpm para instalar e não deixar uma dependência ser instalada mais de 1 vez.
Mas isso não seria nada fácil poderiam ficar pacotes orfaos após remover um software.. Complicado isso.

shoujo
(usa Slackware)

Enviado em 14/02/2016 - 19:39h

Pois é mas no Mac eles usam uma tolkit que trabalha nativamente dessa forma..
Microsoft também tem sua forma de funcionar.
Já o Linux funciona diferente acho que seria bem difícil ter que contornar essas diferenças

removido
(usa Nenhuma)

Enviado em 14/02/2016 - 19:39h

O mais próximo que temos desse modelo de aplicativos do OSX é o GoboLinux...

shoujo
(usa Slackware)

Enviado em 14/02/2016 - 19:42h

Já testei o gobo Linux, na verdade eles so fazem um atalho da pasta /usr para /programs e tals, não tem nada de incrivel o que eles fazem.. Acho uma perca de tempo um link simbólico, que so complica na hora de compilar os softwares.

Thihup
(usa Manjaro Linux)

Enviado em 14/02/2016 - 19:49h

Esse tópico vai ficar lotado em pouco tempo hehe.

Pelo que pude analizar e pensar, seria um Linux por baixo, e os aplicativos não seriam instalados nativamente. Mas como existiriam o básico do sistema por baixo, se a pessoa quiser compilar sua própria aplicação [./configure && make && sudo make install] também funcionaria.

E assim, se o aplicativo precise de uma biblioteca, vamos usar o caso do Windows, as .dll:

O aplicativo pede pelo ".dll", ele procura na pasta primeiro, se tiver, é essa ".dll" que será utilizada. Se não tiver na pasta, ele buscará pelo PATH pela ".dll" para utilizar. Se ainda assim não existir dai geraria um erro.

Para contornar isso eu pensei em criar um arquivo, por exemplo, que está escrito quais são as bibliotecas [exemplo: libs.deps], e antes de ser "supostamente instalado", ele faria a verificação no diretório e depois no PATH, se existisse, ele "supostamente instalaria".

Mas ainda é cedo para pensar nisso. Precisaria pensar uma forma de criar um aplicativo que tivesse as bibliotecas primeiro hehê.

Eu baixei o Teamviewer e é bem nesse esquema que eu gostaria que fosse feito, tem como instalar nativamente e só "supostamente". Só que claro, em modo gráfico.

[]'s

T+

--

Att,

Thiago Henrique Hüpner

(Mensagem scaneada pelo antivírus........ops! não precisa, afinal eu uso Linux!)

removido
(usa Nenhuma)

Enviado em 14/02/2016 - 19:55h

Eles fazem esse esquema para manter a compatibilidade com os pacotes tradicionais. Sem isso, nenhum software instalado por source code iria funcionar nesse sistema...