Por que todos os aplicativos Mac não são facilmente portáteis para Linux?


15

Como o sistema operacional Apple OS-X é um derivado UNIX (BSD) e a arquitetura Mac (Intel) subjacente é a mesma, por que não é muito simples colocar aplicativos específicos da Apple em execução no Linux?

Respostas:


23

O OS X é realmente (principalmente) o shell gráfico proprietário sobre o BSD. Para criar um aplicativo OS X GUI, é necessário seguir a API que a Apple expôs e, portanto, essa não é uma plataforma cruzada e não é facilmente portátil.
É por isso que a maioria das bibliotecas é facilmente portada (na verdade, a maioria é desenvolvida no Linux) para o Linux, mas não seus shells gráficos.

Em uma nota lateral: Existem estruturas por aí com as quais você pode criar aplicativos GUI de plataforma cruzada. Qt vem à mente. Mas o fato de essas estruturas serem de plataforma cruzada também torna os aplicativos criados com eles menos amigáveis ​​em uma plataforma específica do que em um aplicativo GUI "nativo". Essas estruturas tendem a fazer tudo parecer genérico entre plataformas, o que, no caso da Apple, é ruim, porque a Apple criou uma experiência de usuário muito específica que não se "encaixa" facilmente em outras plataformas.

Editar (para incorporar os comentários na resposta - obrigado @Nick, @kbisset e @John):
Uma solução seria portar todo o shell gráfico do OS X (as bibliotecas Cocoa / Core de código fechado - o que torna o OS X verdadeiramente único ) para Linux. E tecnicamente, a Apple poderia fazer isso com bastante facilidade, mas eles não têm razão, pois todo o modelo de negócios é a singularidade de toda a plataforma - hardware e software.
É CONCEBÍVEL que alguém possa tentar clonar as bibliotecas, mas isso levaria décadas para ser feito, e provavelmente nunca estaria certo devido a todas as chamadas não documentadas que precisariam ser replicadas.


Por que o shell gráfico proprietário não pode ser portado com relativa facilidade para Linux se estiver sendo executado no BSD? Eu entendi o problema quando a arquitetura subjacente era diferente, mas agora a arquitetura subjacente é apenas Intel, por que o shell gráfico não é apenas mais uma biblioteca?
31140 Nick Pierpoint

8
Duas razões. Primeiro, é mais do que apenas um shell gráfico. É uma camada inteira acima do Unix, na qual a Apple trabalha há anos. Segundo, o código não está disponível. Portanto, ele precisaria ser reescrito do zero. A Apple provavelmente poderia fazer isso em um curto período de tempo, mas não há motivos para isso.
KeithB

1
Então ... para a Apple, pelo menos, não há realmente um problema técnico - eles podem migrar o OS-X para rodar no Linux com relativa facilidade, pois já o executam no UNIX. Obviamente, é um grande negócio para todos os outros, pois o código é de código fechado e não há API totalmente publicada. Esse é um resumo justo?
22640 Nick Pierpoint

3
Nick: Essencialmente, sim. A Apple não tem interesse em mudar o OSX para uma plataforma Linux; por que eles deveriam investir tanto em sua plataforma Darwin de código aberto (a camada BSD) e em suas bibliotecas Cocoa / Core * de código fechado (que é o que torna o OSX verdadeiramente único). Todo o modelo de negócios é a exclusividade de toda a plataforma - hardware e software. É CONCEBÍVEL que alguém possa tentar clonar as bibliotecas, mas isso levaria décadas para ser feito, e provavelmente nunca estaria certo devido a todas as chamadas não documentadas que precisariam ser replicadas. E para que fim?
19269 John Rudy

4
O GNUStep é uma implementação de código aberto de muitas das principais bibliotecas que agora estão no OS X, no entanto, a Apple adicionou muitas desde então, portanto, portar ainda não é tão fácil: wiki.gnustep.org/index.php/Cocoa
TRS-80

2

Por aplicativos específicos da Apple, você quer dizer aplicativos GUI? Depois que você se move acima da linha de comando, existem APIs específicas da Apple para tudo (gráficos, som etc.) que não são suportadas no Linux, portanto, você não pode facilmente portar aplicativos.


1

A camada gráfica não é a mesma. OS X usa uma estrutura gráfica proprietária, o linux usa X (X11 / X.org)

Quase todos os aplicativos nativos do OS X usam estruturas como Cocoa, CoreAnimation e assim por diante, disponíveis apenas no OS X.

Por exemplo, digamos que você tenha um aplicativo que armazene uma senha para o usuário - no OS X, isso usaria o sistema Keychain e as APIs relevantes. Se você fosse portar isso para o Linux, não há equivalente direto, então você teria que reimplementar todo esse recurso. Esse é um recurso minúsculo e exigiria uma grande reescrita.

Se você escrever seu aplicativo usando uma biblioteca GUI de plataforma cruzada, como GTK, Qt ou wxWidgets, e portar será muito mais fácil (ou "possível") - mas os sistemas operacionais ainda serão muito diferentes em termos de interface do usuário (por exemplo, SO X usa uma barra de menus separada, enquanto o Linux tende a ter sua barra de menus para cada janela)

Uma das melhores portas de plataforma cruzada que eu já vi é a Transmission , que implementa sua principal funcionalidade como uma biblioteca (que contém o mínimo de código específico de plataforma possível) e, em seguida, criando GUIs nativas para cada plataforma, separadamente. Isso significa que cada porta compartilha muito código, mas todas têm boas interfaces nativas (em vez de uma única interface que se encaixa perfeitamente no Linux, mas está deslocada no OS X ou vice-versa)

Existe um projeto chamado Cocotron que "visa implementar uma API Objective-C de plataforma cruzada semelhante à descrita na documentação Cocoa da Apple Inc." que potencialmente tornaria a transferência muito mais fácil, mas parece haver muito pouca atividade nos últimos tempos. (a última postagem do blog foi em dezembro de 2008)


1

Como a maioria dos aplicativos depende muito mais do que o processador e a arquitetura subjacente da máquina em que estão sendo executados. Eles também dependem dos kits de ferramentas da interface do usuário e de outras bibliotecas específicas da plataforma.

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.