LINUX.ORG.RU
ФорумTalks

Мечты о Linux API


3

3

Казалось бы, в современном Linux благодаря стандартам freedesktop можно просто взять и собрать кросс-дистрибутивный пакет для любого графического приложения, который будет располагаться в хомяке и таскать с собой все нужные библиотеки.

Делается это так:

  • .desktop кладём в ~/.local/share/applications
  • иконку к .desktop кладём в ~/.local/share/icons
  • приложение и его библиотеки кладём в ~/.local/share/$VENDOR/$APP
  • типовой shell-скрипт с LD_LIBRARY_PATH кладём в ~/bin
  • приложение пишется так, чтобы не мусорить в хомяк и использовать /tmp, XDG_DATA_DIR, XDG_CONFIG_DIR

И всё работает, и любая DE видит эту программу, и пользователи плачут от радости.

Но не тут-то было. Потому что в Linux нет API с обратной бинарной совместимостью. Потому что LSB — лживый недостандарт, предназначенный исключительно для подсаживания дурачков на вендорную иглу и сколачивания бабла (Ульрих Дреппер, бывший лидер проекта GLIBC, писал об этом ещё в 2005-м; я проверил ситуацию пару дней назад — и увидел, что LSB dll hell проявится даже в таких «правильных» дистрибутивах, как OpenSUSE).

А как бы всё-таки мог выглядеть этот API, который должен быть на любом CD с любым дистрибутивом и должен появляться сразу после установки в любом дистрибутиве? Тут три критерия: минималистичность, привлечение разработчиков с других платформ и самодостаточность.

По моим современным личным представлениям, любая библиотека в идеале выполняет ровно одну из двух задач: предоставляет API или является фреймворком. Библиотека-API минималистична и массштабируема, но требует знания матчасти и множественных проверок кодов возврата: на ней можно написать быстрый и качественный движок (графический, звуковой, рендеринг шрифтов), но использовать такое в приложении напрямую без обёрток может только недалёкий человек. Библиотека-фреймворк, напротив, выполняет общие задачи не задаваясь максимальной гибкостью, но зато с удобством; при этом фреймворк должен либо иметь обратную бинарную совместимость в течение многих лет, либо его надо встраивать в пакет с приложением; примером первого подхода является Qt, примером второго - cocos2d-x.

Исходя из этих представлений, я вижу так:

  • Linux API должен иметь два слоя: первым будет максимально привлекательный фреймворк с обратной совместимостью, вторым будет набор кроссплатформенных массштабируемых сишных библиотек с максимальной гибкостью и производительностью.
  • Первым слоем должен быть Qt5 — программы на нём практически не требуют дополнительных библиотек и легко переносимы на Windows, OSX (а теперь отчасти и на android с iOS). Вкупе с поддержкой QML и javascript это будет сильнее всего привлекать людей к разработке и портированию качественных приложений для/на Linux.
  • Вторым слоем должен быть набор библиотек, позволяющих общаться с любой важной внешней сущностью. Шрифты, работа с OpenGL, создание окна и контекста OpenGL, работа со звуковыми устройствами, открытие URL по клику и вывод уведомлений — все эти штуки приложение не сможет нормально сделать само или с помощью библиотек в своём пакете. Это должен быть внешний API.
  • Во второй слой точно должны попасть: OpenGL, OpenAL, fontconfig и freetype. Библиотеки png и jpeg попадать не обязаны — да, они часто используются, но они не работают с внешней средой и легко могут быть в составе пакета приложения. Надо также разработать библиотеки (а не утилиты командной строки и не dbus-интерфейсы) для работы с DE (appmenu, прогрессбар и badges на иконке приложения в лаунчере, уведомления)
  • За размер пакетов бояться не стоит: zip и bz2 очень хорошо жмут бинарники, link-time optimization и strip вырезают из них лишнее, а наличие Qt5 в первом слое API уже даст кучу крайне лёгких Qt-приложений для узких задач, более опытные и уверенные в себе разработчики смогут сделать относительно лёгкое приложение на втором слое API.

Какие ещё библиотеки должны попасть во второй слой API? И может быть, я что-то упустил из виду?

P.S. Генту идёт в лес. Если вы готовы собирать то же приложение из исходников или оптимизируете работу сервера — флаг вам в руке, но о готовых пакетах с десктопными приложениями забудьте, сами же отказались от этого в своей идеологии.

★★★★

Последнее исправление: quiet_readonly (всего исправлений: 1)

Ответ на: комментарий от carasin

Сейчас попрут аналогии с виндой / Progra~1.

Матчасть изучи, пожалуйста. Android, iOS, Mac OSX поступают точно также, как я описал. И LSB по словам его разработчиков к той же цели стремился (хотя на деле цели совсем другие).

Если же в винде штука сделана плохо, это не означает ущербность принципа. Но даёт хорошее подспорье для создания более грамотной реализации.

quiet_readonly ★★★★
() автор топика

Ну, в Ubuntu нечто подобное уже пилится. Есть Ubuntu SDK (правда, пока вроде как только под Ubuntu Touch), использующий таки да, Qt5, и пилится новый формат пакетов для локальной установки без зависимостей, по типу андроидовского.

reserved
()
Ответ на: комментарий от mono

Ты изобрел LBS или мне показалось?

Ссылка на пост Ульриха Дреппера у меня стоит не зря. LSB лжив и предназначен для «сертификации», которая в реальности не значит ничего, но позволяет размахивать бумажкой. Примерно как Альт и Роса с сертификацией ФСТЭК.

quiet_readonly ★★★★
() автор топика
Ответ на: комментарий от reserved

Да, и они мне этим очень нравятся. Но в Ubuntu SDK пока нет второго слоя API. Точнее есть OpenGL/OpenGLES, но не более.

quiet_readonly ★★★★
() автор топика
Ответ на: комментарий от TERRANZ

как насчёт привлекательности для разработчиков?

Первый слой привлекает общим качеством фреймворка Qt5, и обилием хороших инструментов разработчика для него. Второй слой привлекает наличием всех широко известных открытых библиотек — те же OpenAL и OpenGL поддерживаются Apple на iOS и MacOSX без ограничений. Исходники портированного на iOS CURL есть на сайте Apple, аналогично с другими открытыми библиотеками. Патчи за пару лет вроде бы уже успели попасть во все апстримы.

quiet_readonly ★★★★
() автор топика
Последнее исправление: quiet_readonly (всего исправлений: 1)
Ответ на: комментарий от quiet_readonly

Между тем, я не высказывал своего оценочного суждения данного принципа. Просто здесь полно крикунов, кричащих про курс Linux'а в сторону win-style и про отход от принципов unix-way. Мне-то на самом деле пофиг ;D

carasin ★★★★★
()
Ответ на: комментарий от reserved

Да заколебали вы со своей убантой, все фразы только в будущем времени, поставил 13.10 вчера, более глючный кусок дерьма сложно вообразить, и с огромным удовольствием накатил милейшую 20федору с гномощелью. Небо и днище. Днище убунта ваша, только от линукса народ отпугивать ею. Выдохнул.

druganddrop-2 ★★
()
Последнее исправление: druganddrop-2 (всего исправлений: 1)
Ответ на: комментарий от druganddrop-2

накатил милейшую 20федору с гномощелью

Я вот думаю, откуда берутся треды с -20, вот откуда ноги растут оказывается.

UVV ★★★★★
()
Ответ на: комментарий от KendovNorok

Ну давайте смотреть правде в глаза, сборка одной и той же DE в разных дистрибутивах может отличаться, а Unity вообще прибита гвоздями к Ubuntu.

mono ★★★★★
()

Сборка пакетов - задача ментейнеров каждого конкретного дистрибутива.

Однако разработчики могут держать свои собственные репозитории для избранных дистрибутивов.

Chaser_Andrey ★★★★★
()
Ответ на: комментарий от Apple-ch

Пруф? Помню, что он говорил что-то типа «We never break userspace».

Ttt ☆☆☆☆☆
()
Последнее исправление: Ttt (всего исправлений: 1)
Ответ на: комментарий от Apple-ch

Он про внутриядерную кухню говорил.

GAMer ★★★★★
()
Ответ на: комментарий от Jetty

Читай внимательнее

в рамках мажорной версии

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

Ttt ☆☆☆☆☆
()
Ответ на: комментарий от druganddrop-2

Прочитал сообщение, подумал - «да он псих какой-то». Увидел аватарку - все встало на свои места.

KDE попробуй, что ли. Не нервничай, главное.

KendovNorok
()
Ответ на: комментарий от druganddrop-2

милейшую
20федору с гномощелью

OMG они существуют!

AX ★★★★★
()

приложение и его библиотеки кладём в ~/.local/share/$VENDOR/$APP

давай досвидания

x0r ★★★★★
()

приложение и его библиотеки кладём в ~/.local/share/$VENDOR/$APP

Говностандарты должны сдохнуть.

Надо также разработать библиотеки (а не утилиты командной строки и не dbus-интерфейсы) для работы с DE (appmenu, прогрессбар и badges на иконке приложения в лаунчере, уведомления)

Даже если под этими библиотеками будут DBus-интерфейсы?

И может быть, я что-то упустил из виду?

Как минимум то, что приложений на Qt5 пока нет. Да и вообще какая-то маниловщина - кто всё это будет делать и почему план не зафейлится, как LSB?

tailgunner ★★★★★
()
Ответ на: комментарий от Chaser_Andrey

Сборка пакетов - задача ментейнеров каждого конкретного дистрибутива.

Господь Бог завещал не возжелать жены ближнего своего.

Однако разработчики могут держать свои собственные репозитории для избранных дистрибутивов.

по блату?

quiet_readonly ★★★★
() автор топика
Последнее исправление: quiet_readonly (всего исправлений: 1)
Ответ на: комментарий от Jetty

теоретик, что тут еще скажешь. Дай угадаю, а «софт» ты пишешь в qtcreator'е.

А ещё у меня есть неслабая пачка принятых в апстрим патчей к самому QtCreator.

quiet_readonly ★★★★
() автор топика

«Как нам обустроить Россию», красноглазая версия?

leave ★★★★★
()
Последнее исправление: leave (всего исправлений: 1)
Ответ на: комментарий от druganddrop-2

Ничего общего между UnityDE и Gnome нет. Единственное, что их связывает — библиотека GTK. Да и то, вроде обещали переехать на Qt.

ivanlex ★★★★★
()

Потому что в Linux нет API с обратной бинарной совместимостью

Правильно, оно не нужно. Если софт не работает на новой версии АПИ, достаточно его немого поправить и пересобрать.

ya-betmen ★★★★★
()
Ответ на: комментарий от ivanlex

Не дистрибутив зависит от DE, а DE от дистрибутива.

mono ★★★★★
()
Ответ на: комментарий от Ttt

Нельзя сказать про обратную совместимость в рамках мажорной версии, потому что кардинальное изменение АПИ и ведет к смене мажорной версии.

Jetty ★★★★★
()
Ответ на: комментарий от quiet_readonly

Каждый порядочный индус всеравно больше написал. И чё?

Jetty ★★★★★
()
Ответ на: комментарий от Ttt

У себя спроси. Это же ты опровергаешь тезис «stable API nonsense».


P.S. Ага, а щас ты напишешь «где я такое говорил, я ничего не опровергаю».

Jetty ★★★★★
()

Библиотек много, и все разные, в одно место не запихнёшь.

Programmist11180 ★★★
()

который будет располагаться в хомяке и таскать с собой все нужные библиотеки.

Не юниксвейно. А к чему приводит отход от юниксвея, объяснять надо?

cvs-255 ★★★★★
()
Последнее исправление: cvs-255 (всего исправлений: 1)
Ответ на: комментарий от ivanlex

Ничего общего между UnityDE и Gnome нет. Единственное, что их связывает — библиотека GTK. Да и то, вроде обещали переехать на Qt.

На данный момент в Unity все программы из окружения гномовские (хоть и с патчами). Это создаёт сильную связь и море проблем — гномеры постоянно что-то ломают и судьба других DE их при этом не волнует ни капли; разработчки Ubuntu и Mint не всегда успевают патчами пофиксить сломанное идиотами.

quiet_readonly ★★★★
() автор топика
Ответ на: комментарий от ya-betmen

Правильно, оно не нужно. Если софт не работает на новой версии АПИ, достаточно его немого поправить и пересобрать.

Тысячи, тысячи, тыщи пересборок,
сто тыщ костыликов, пять тыщ подпорок

(Noise MC remake)
quiet_readonly ★★★★
() автор топика
Ответ на: комментарий от quiet_readonly

На данный момент в Unity все программы из окружения гномовские (хоть и с патчами).

А вот хороший вопрос, если я поставлю себе Ubuntu с Unity и рядом поставлю GNOME что будет с приложниями? Тот-же nautilus из GNOME потрет патченый из Unity, или в бубунтарепах только патченый лежит? Или они обозвали их по другому?

Deleted
()
Ответ на: комментарий от Jetty

Нельзя сказать про обратную совместимость в рамках мажорной версии, потому что кардинальное изменение АПИ и ведет к смене мажорной версии.

Не у всех. И не все стараются уменьшить частоту появления несовместимых версий.

quiet_readonly ★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.