¿Por qué no todas las aplicaciones de Mac son fácilmente transportables a Linux?

15

Dado que el sistema operativo Apple OS-X es un derivado de UNIX (BSD) y la arquitectura subyacente de Mac (Intel) es la misma, ¿por qué no es muy sencillo ejecutar aplicaciones específicas de Apple en Linux?

linux macos mac portable bsd Nick Pierpoint
fuente

Respuestas:

23

OS X es en realidad (principalmente) el shell gráfico patentado sobre BSD. Para crear una aplicación OS X GUI, uno tiene que seguir la API que Apple ha expuesto, y por lo tanto no es multiplataforma y no es fácilmente portátil.
Es por eso que la mayoría de las bibliotecas se portan fácilmente (en realidad, la mayoría se desarrollan en Linux) a Linux, pero no a sus shells gráficos.

Como nota al margen: existen marcos con los que puede crear aplicaciones GUI multiplataforma. Qt viene a mi mente. Pero el hecho de que esos marcos sean multiplataforma también hace que las aplicaciones creadas con ellas sean menos fáciles de usar en una plataforma específica que una aplicación GUI "nativa". Esos marcos tienden a hacer que todo parezca genérico en todas las plataformas, lo que en el caso de Apple es malo, porque Apple creó una experiencia de usuario muy específica que no "encaja" fácilmente en otras plataformas.

Editar (para incorporar los comentarios en la respuesta - gracias @ Nick, @kbisset y @John):
Una solución sería la de portar el sistema operativo entero X consola gráfica (bibliotecas Cacao / núcleo del código cerrado - que es lo que hace realmente único OS X ) a Linux. Y técnicamente, Apple podría hacerlo bastante fácil, pero no tienen razón para hacerlo, ya que todo su modelo de negocio es la singularidad de toda su plataforma: hardware y software.
Es CONCEBIBLE que alguien pueda intentar clonar las bibliotecas, pero eso llevaría décadas de trabajo, y probablemente nunca sería correcto debido a todas las llamadas indocumentadas que tendrían que ser replicadas.

fretje
fuente
¿Por qué el shell gráfico propietario no se puede portar con relativa facilidad a Linux si se ejecuta en BSD? Entendí el problema cuando la arquitectura subyacente era diferente, pero ahora la arquitectura subyacente es solo Intel, entonces ¿por qué el shell gráfico no es solo una biblioteca más?
Nick Pierpoint
8
Dos razones. Primero, es más que solo un shell gráfico. Es una capa completa sobre Unix, en la que Apple ha estado trabajando durante años. Segundo, el código no está disponible. Por lo tanto, debería reescribirse desde cero. Apple probablemente podría hacerlo en un corto período de tiempo, pero no hay razón para que lo hagan.
KeithB
1
Entonces ... para Apple, al menos, no hay realmente un problema técnico: podrían migrar OS-X para que se ejecute en Linux con relativa facilidad, ya que ya lo tienen en UNIX. Obviamente es un gran problema para todos los demás, ya que el código es de código cerrado y no hay una API completamente publicada. ¿Es ese un resumen justo?
Nick Pierpoint
3
Nick: Básicamente sí. Apple no tiene interés en trasladar OSX a una plataforma Linux; ¿Por qué deberían hacerlo cuando han invertido tanto en su plataforma Darwin de código abierto (la capa BSD) y sus bibliotecas de código cerrado Cocoa / Core * (que es lo que hace que OSX sea realmente único). Todo su modelo de negocio es la singularidad de toda su plataforma: hardware y software. Es CONCEBIBLE que alguien pueda intentar clonar las bibliotecas, pero eso llevaría décadas de trabajo, y probablemente nunca sería correcto debido a todas las llamadas indocumentadas que tendrían que ser replicadas. ¿Y con qué fin?
John Rudy el
44
GNUStep es una implementación de código abierto de muchas de las bibliotecas principales que ahora se encuentran en OS X, sin embargo, Apple ha agregado muchas desde entonces, por lo que la transferencia aún no es tan fácil: wiki.gnustep.org/index.php/Cocoa
TRS-80
2

Por aplicaciones específicas de Apple, ¿se refiere a aplicaciones GUI? Una vez que se mueva por encima de la línea de comandos, hay API específicas de Apple para todo (gráficos, sonido, etc.) que no son compatibles con Linux, por lo tanto, no puede portar aplicaciones fácilmente.

marca
fuente
1

La capa gráfica no es la misma, en absoluto. OS X usa un marco gráfico patentado, Linux usa X (X11 / X.org)

Casi todas las aplicaciones nativas de OS X usan marcos como Cocoa, CoreAnimation, etc., que solo están disponibles en OS X.

Por ejemplo, supongamos que tiene una aplicación que almacena una contraseña para el usuario; en OS X, esto usaría su sistema Keychain y las API relevantes. Si tuviera que portar esto a Linux, no hay un equivalente directo, por lo que tendría que volver a poner en práctica toda esta característica. Esa es una característica pequeña, y requeriría una gran reescritura.

Si escribe su aplicación utilizando una biblioteca GUI multiplataforma como GTK, Qt o wxWidgets, y la transferencia será mucho más fácil (o "posible"), pero los sistemas operativos siguen siendo muy diferentes en términos de IU (por ejemplo, SO X usa una barra de menú separada, mientras que Linux tiende a tener su barra de menú para cada ventana)

Uno de los mejores puertos multiplataforma que he visto es Transmission , que implementa su funcionalidad principal como una biblioteca (que contiene el menor código específico de plataforma posible), luego crea GUI nativas para cada plataforma, por separado. Esto significa que cada puerto comparte mucho código, pero todos tienen buenas interfaces nativas (en lugar de una única interfaz que se adapta muy bien a Linux, pero está fuera de lugar en OS X, o viceversa)

Hay un proyecto llamado Cocotron que "tiene como objetivo implementar una API Objective-C multiplataforma similar a la descrita por la documentación Cocoa de Apple Inc." que potencialmente facilitaría mucho la transferencia, pero parece haber muy poca actividad en los últimos tiempos. (la última publicación de blog fue en diciembre de 2008)

dbr
fuente
1

Porque la mayoría de las aplicaciones dependen mucho más que el procesador y la arquitectura subyacente de la máquina en la que se están ejecutando. También dependen de kits de herramientas de interfaz de usuario y otras bibliotecas específicas de la plataforma.

Kent Boogaart
fuente