Почему не все приложения Mac легко переносимы на Linux?


15

Поскольку операционная система Apple OS-X является производной от UNIX (BSD), а базовая архитектура (Intel) Mac одинакова, почему не так просто запустить приложения для Apple, работающие в Linux?

Ответы:


23

OS X на самом деле (в основном) проприетарная графическая оболочка поверх BSD. Чтобы создать приложение OS X GUI, нужно следовать API, выставленному Apple, и, следовательно, это не кроссплатформенный и не легко переносимый.
Вот почему большинство библиотек являются легко портированы ( на самом деле большинство из них разработаны на Linux) для Linux , но не их графических оболочек.

На заметку: существуют фреймворки, с помощью которых вы можете создавать кроссплатформенные приложения с графическим интерфейсом. Qt приходит на ум. Но тот факт, что эти платформы являются кроссплатформенными, также делает приложения, созданные с их помощью, менее удобными для пользователя на конкретной платформе, чем «родное» приложение с графическим интерфейсом. Эти фреймворки, как правило, заставляют все выглядеть универсально на разных платформах, что в случае с Apple плохо, потому что Apple создала очень специфический пользовательский интерфейс, который не просто «вписывается» в другие платформы.

Редактировать (чтобы включить комментарии в ответ - спасибо @Nick, @kbisset и @John):
Решением было бы перенести всю графическую оболочку OS X (библиотеки Cocoa / Core с закрытым исходным кодом - что делает OS X действительно уникальной ) в Linux. И технически Apple может сделать это довольно легко, но у них нет причин для этого, поскольку вся их бизнес-модель является уникальностью всей их платформы - аппаратного и программного обеспечения.
Можно предположить, что кто-то может попытаться клонировать библиотеки, но на это уйдут человеческие десятилетия, и, вероятно, он никогда не будет прав из-за всех недокументированных вызовов, которые необходимо будет повторить.


Почему нельзя проприетарную графическую оболочку относительно легко перенести на Linux, если она работает на BSD? Я понял проблему, когда базовая архитектура отличалась, но теперь базовая архитектура - это просто Intel, тогда почему графическая оболочка - это не просто еще одна библиотека?
Ник Пирпойнт

8
Две причины Во-первых, это больше, чем просто графическая оболочка. Это целый слой над Unix, над которым Apple работает годами. Во-вторых, код недоступен. Так что это должно быть переписано с нуля. Apple может сделать это за короткий промежуток времени, но для этого нет причин.
KeithB

1
Так что ... для Apple, по крайней мере, на самом деле нет технической проблемы - они могут относительно легко перенести OS-X для работы в Linux, поскольку они уже работают в UNIX. Очевидно, что это большое дело для всех остальных, поскольку код имеет закрытый исходный код и полностью не публикуется API. Это справедливое резюме?
Ник Пирпойнт

3
Ник: По сути, да. Apple не заинтересована в переносе OSX на платформу Linux; зачем им, когда они так много инвестировали в свою платформу Darwin с открытым исходным кодом (уровень BSD) и в свои библиотеки Cocoa / Core * с закрытым исходным кодом (что делает OSX по-настоящему уникальным). Вся их бизнес-модель заключается в уникальности всей их платформы - аппаратного и программного обеспечения. Можно предположить, что кто-то может попытаться клонировать библиотеки, но на это уйдут человеческие десятилетия, и, вероятно, он никогда не будет прав из-за всех недокументированных вызовов, которые необходимо будет повторить. И для чего?
Джон Руди

4
GNUStep - это реализация с открытым исходным кодом многих базовых библиотек, которые в настоящее время находятся в OS X, однако с тех пор Apple добавила многие из них, поэтому перенос по-прежнему не так прост: wiki.gnustep.org/index.php/Cocoa
TRS-80

2

Под приложениями для Apple вы подразумеваете приложения с графическим интерфейсом? Когда вы перемещаетесь над командной строкой, появляются специальные API-интерфейсы Apple для всего (графика, звук и т. Д.), Которые не поддерживаются в Linux, поэтому вы не можете легко портировать приложения.


1

Графический слой совсем не тот. OS X использует проприетарную графическую структуру, Linux использует X (X11 / X.org)

Почти все собственные приложения OS X используют такие инфраструктуры, как Cocoa, CoreAnimation и т. Д., Которые доступны только в OS X.

Например, скажем, у вас есть приложение, которое хранит пароль для пользователя - в OS X это будет использовать его систему Keychain и соответствующие API. Если бы вы перенесли это на Linux, прямого эквивалента не было бы, поэтому вам пришлось бы повторно реализовать всю эту функцию. Это крошечная функция, которая потребует большой переписывания.

Если вы пишете свое приложение, используя кросс-платформенную библиотеку GUI, такую ​​как GTK, Qt или wxWidgets, и перенос будет намного проще (или «возможен»), но операционные системы по-прежнему сильно отличаются с точки зрения пользовательского интерфейса (например, ОС X использует отдельную строку меню, в то время как у Linux, как правило, есть строка меню для каждого окна)

Одним из лучших кроссплатформенных портов, которые я когда-либо видел, является Transmission , который реализует свою основную функциональность в виде библиотеки (которая содержит как можно меньше кода для конкретной платформы), а затем создает собственные графические интерфейсы для каждой платформы отдельно. Это означает, что каждый порт имеет много общего кода, но у всех есть хорошие, собственные интерфейсы (а не один интерфейс, который прекрасно подходит для Linux, но неуместен в OS X, или наоборот)

Существует проект под названием Cocotron, который "нацелен на реализацию кроссплатформенного API Objective-C, аналогичного описанному в документации Apple Inc. по какао", который потенциально мог бы значительно упростить перенос, но в последнее время активность, по-видимому, очень мала (последнее сообщение в блоге было в декабре 2008 года)


1

Поскольку большинство приложений зависят от гораздо большего, чем процессор и базовая архитектура компьютера, на котором они работают. Они также зависят от наборов инструментов пользовательского интерфейса и других специфичных для платформы библиотек.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.