Привет, Хабр! Меня зовут Олег Ивченков, и я управляю группой компаний Setere. У нас есть продукт: берем скан бумажного документа, распознаем его и переводим в редактируемый формат. Классическая OCR-система. Под капотом — C++, QT, QML, немного python`а. Работаем под Linux только как десктопное приложение. И именно о Linux я хотел поговорить. У меня накопилось много опыта за более чем десять лет разработки, и хочу рассказать о тех проблемах, которые сейчас вижу в области разработки под Linux.
Главную проблему я бы озвучил так: «неконтролируемое множество». И от неё ответвляются много разных других. О них-то я и расскажу в статье, которая должна быть полезна всем, кто так или иначе связан с разработкой под Linux. Если вы прочитаете материал и почувствуете то же, что и я — добро пожаловать в комментарии, обсудим!
Еще год назад, в рамках круглого стола «Импортозамещение» Форума ассоциации Руссофт я предложил профессионалам отрасли поговорить о такой важной теме, как «реалии нативной разработки для отечественных операционных систем». Точнее не просто реалии, а — этой самой разработки сложности, по моим ощущениям приобретающие как минимум линейный рост. Прошедший год показал, что рост проблем не линейный, так что основные тезисы того выступления и несколько новых деталей стали моей первой публикацией на Хабре.
Боль не только моей компании, но и компаний коллег, начну описывать с общей информации по рынку. Согласно данным, любезно предоставленным ассоциацией «Руссофт» — год от года время на разработку решений для Windows в России постепенно снижается, а для систем семейства Linux — неуклонно растет. Помимо достаточно очевидного факта снижения интереса к Windows в нашей стране в принципе, увеличение времени разработки для Linux‑систем связано и с еще одним немаловажным фактором. Этот фактор — существенно возросшая сложность разработки, связанная с количеством Linux‑систем, их технологическим разнообразием.
Совместимость и вендоры: как подружить продукт со всеми версиями
Согласно различным данным, количество существующих российских десктопных операционных систем в прошлом году составляло от 30 до 40 (в реестре российского ПО по классу 2.09 — операционные системы общего назначения летом 2023 года насчитывалось 38 различных продуктов), а в этом уже перевалило за 80. Не думаем, что найдется вендор, обеспечивающий совместимость со всеми этими системами. Даже с половиной из них. Откровенно говоря, в этом, пожалуй, и необходимости нет никакой.
Те три операционные системы, которые компания выбрала и совместимость с которыми обеспечивает, оптимальны для обеспечения качественного решения проблемы импортозамещения OCR. Но даже это — непросто. Судите сами, только для трех ОС нам необходимо разрабатывать, тестировать и поддерживать 7 различных дистрибутивов. Заказчики покупают ОСи, затем отказываются их обновлять. Естественно, вендоры и разработчики всегда стараются делать продукт лучше, не стоять на месте. А вот заказчик обновляться готов далеко не всегда. Вполне возможно, что с выходом новых минорных, не говоря уже о мажорных, версий операционок нам придется собрать еще один, или два, или три дистрибутива. И поддерживать их. Мне эта ситуация не очень нравится. А какие варианты?
Проблема библиотек: кто и что поддерживает
Почему так вообще происходит? В нашем случае — из‑за различных версий поддерживаемых российскими операционными системами библиотек и технологий. В таблице представлены несколько достаточно популярных из них.
Посмотрите на разницу в версиях. Кстати, напомню, далеко не все библиотеки имеют обратную совместимость. Я помню не одну и не две неприятные ситуации, когда заказчик всё-таки обновил ОС, обновил библиотеки, не имеющие обратной совместимости, и продукт перестал корректно работать из-за отсутствия одной важной функции именно в старой версии библиотеки.
Поехали дальше. У нас выходит серверная версия продукта, делает её та же команда, которая занимается десктопом. Предположим, защищенных версий, требующих сборки отдельного дистрибутива, не будет. И даже не появится никакого запроса на совместимость с четвертой, пятой серверной ОС. Даже в этом случае количество дистрибутивов вырастет до десяти. Если будут и защищенные версии, и появится, например, четвертая ОС, то количество дистрибутивов вырастет до теоретических 13–15 штук. Здорово, правда?
Давайте вернемся к таблице с временными затратами для разработки под разные операционные системы. Лично мне уже не кажется, что время разработки ПО для Linux Family выросло только по причине постепенного ухода Windows с рынка. Как правильно отметили организаторы замечательного мероприятия, на котором я эту проблему озвучивал, прошло всего 1.5 года действительно экстремального импортозамещения, и ситуация в будущем может измениться к лучшему. Но знаете, чего я опасаюсь?
Импортозамещение: помогает или не очень
На сегодняшний день активное импортозамещение коснулось в основном государственного сектора. Объекты КИИ, госкорпорации, ФОИВы и РОИВы. Но уже прямо сейчас ведется разработка новых операционных систем для коммерческого сектора (речь об ОС от Softline, где за основу взята МСВСфера). Уже есть операционные системы, не относящиеся к Linux Family, написанные с нуля. И речь далеко не о ноунейм системах (речь о Kaspersky OS). Есть вероятность, что китайские корпорации будут продвигать в нашем коммерческом секторе свои решения (ЭйлерОС от Huawei).
Уход в web или «облака» для основных заказчиков — государственных компаний или объектов критической инфраструктуры — не вариант, так как в первую очередь по причине ИБ‑составляющей не у всех есть возможность такие версии продуктов использовать.
Проблема шире и сейчас проявляется в самых формах и с неожиданной стороны. Например, вот в своем интервью гендиректор «Группы Астра» Илья Сивцев говорит о ландшафте рынка ИТ-продуктов и схожей проблеме многообразия. Кроме того, я читал много публикаций о проблеме количества сценариев в учебных программах и программах ИТ-наставничества. Темы разные, но боль-то схожая: любые нерегулируемые сущности стремятся заполонить собой весь объем и даже «с горкой». Бритва Оккама нужна и срочно, а — по какому принципу резать? Если резать вообще.
Заключение
Коллеги, что мы будем делать со всем этим многообразием? Своими силами решения я пока не нашел, хотя мысли есть: один из технически возможных вариантов – сокращение технологического разрыва между вендорами ОС (по поддерживаемым технологиям разрыв не такой и большой); другой — движение в сторону создания собственной ассоциации производителей нативного ПО и фреймворка. По последнему варианту намерены идти и уже есть первые результаты (о них тоже планирую со временем рассказать).
Буду рад услышать ваши соображения по изложенному в комментариях. Спасибо!
Комментарии (12)
kenomimi
09.07.2024 08:32+3Менять подход надо.
Для актуального дистрибутива выкладываем обычный бинарь или пакет. Для всяких динозавров типа астры - линкуем всё статически, а то, что бинарь большой на выхлопе - так терпите - вы же сами используете дистрибутив, пакеты которого выпущены при палеолите!
Сейчас сам столкнулся с разработкой под астру, и после многочисленных совещаний избрали именно такой подход. Да, он противоречит самой концепции линуксов, но что поделаешь - суровая реальнось диктует свои правила...
webhamster
09.07.2024 08:32Вы действительно думаете, что статически собранный бинарь будет работать без учета версии libc и ядра не той системы? Если повезет - то будет, но чаще всего не везет :)
kenomimi
09.07.2024 08:32Всё, кроме ядра, линкуется статически. Не всегда просто, но реально. Ядро имеет довольно консервативное API, потому что-то сломать даже между мажорами - надо постараться.
В случае проблем совместимости с ядром два пути - говорим заказчику, что надобно обновление, либо за дополнительный прайс временно пересаживаем разработчиков в нужную операционку на виртуалке. Либо третий вариант - AppImage или flatpak, да, это самый жирный вариант (и чуть проблемный при обновлении), но он же и самый рабочий.
c0r3dump
09.07.2024 08:32В реалиях современного российского рынка очень странно не тестировать на всех ос, что есть в списке отечественного ПО или как-там он называется. А если уж тестировать работу на них, то странно и пакеты не собрать для них.
Octabun
09.07.2024 08:32+4У меня есть мысль и я её думаю
Кстати, актуальная в мире версия Python - 3.12.4, но это так, к слову, то ли иллюстрирует проблему, то ли нет...
Неконтролируемое разнообразие - не проблема, ибо разнообразие то контролируемое - лишнее отмирает само. Могло бы отмирать быстрее и от этого стало бы лучше, или ещё как-то явнее контролироваться - да, конечно, но на проблему это не тянет. Ибо если свести разнообразие к минимуму, то остановится развитие, что и отличает баг от фичи.
Скорее проблема в том, что raison d'être приложения - обеспечить знающим и умелым удобство дойки безграмотеых и криворуких, но платёжеспособных. При всей распространённости обычая, Линукс не вполне именно про это. Я ещё помню время, когда ценным результатом работы программиста был алгоритм, совсем не обязательно закодированный, а просто результатом - библиотека. Те времена не отмерли окончательно, Julia и Racket, например, вполне себе бодрячком.
Я вижу как предлагаются решения. Flatpack и AppImage используются и во многих случаях работают. Docker решает ту же проблему и тоже иногда работает. И недавно, когда обнаружился juliaup, я заприметил слона - модное приложение разбирается со своим окружением само. А ведь масса примеров была, что npm что rustup, что pip с его (в хорошем смысле) колёсами. И только Джулия произвела должное впечатление, наверно потому, что относительно недавно, да и известно что люди там сколь занятые, столь и немногочисленные.
Видел как на практике работают два приёма борьюы со вторым корнем проблемы - заказчиком. Если не тыкать его мордой, то он никогда не поинтересуется что и как там внутри обновляется - фигуры умолчания эффективны за пределами самого дикого воображения, спасибо люди добрые показали, сам бы точно не сообразил за сложностью в такое поверить. Искусно составленная смета, где напротив, много чего видно из заслуживающего обсуждения, тоже мощная штука, особенно когда хватает актёрского таланта на околофинальное "но помилуйте, если мы этого не сделаем, то вам придётся не только открыть терминал, но и ввести две команды!!!"
le2
09.07.2024 08:32+3Суровая правда в том что это не российские разработчики ОС какие-то не такие, это десктоп на Линуксе таков какой он есть. Его достоинства перевешивают недостатки для участников рынка. Скорость и цена разработки библиотек важнее удобства использования для прикладных программистов. На совместимость компонентов все забили. Посмотрите, к примеру, что творит "Корпорация Добра". Нет совместимости ни вверх ни в низ. Интерфейсы переписываются в минорных версиях.
Отсюда нужно воспринимать это всё как данность и использовать, как выше написали, Flatpack и прочие подобные инструменты. Не должно вызывать изжоги использование в вашем проекте даже нескольких версий libc и нескольких версий компиляторов.
Всё это не так сложно если иметь культуру разработки. Можно высвободить разработчиков от этой рутины. Сервера могут собирать весь зоопарк сборок самостоятельно. Задачами портирования и совместимости должны заниматься выделенные сотрудники. В этом случае можно не терять время на скорости разработки.
dv0ich
09.07.2024 08:32+1Да, сопровождение софта в Linux это жесть. Если твоя программа зависит от чего-то большего, чем ядро+glibc, то без постоянного допиливания она скорее всего перестанет работать уже через 2-3 года.
kevin_spicy
09.07.2024 08:32+2Не понимаю сути мышления "давайте зарегулируем сегмент рынка любым доступным образом", чтобы развиваться смогли только сильнейшие, у кого уже есть база. Эта "база" им упала с неба в виде законодательства, а не они проведи отдичную работу, чтобы стать лидерами. Нет, мысль конечно понятная, протекционистская... Касперская тоже любит говорить "дорогое государство, а зарегулируйте нам пожалуйста инфобез, а то там так много новых игроков развелось, мы стали меньше зарабатывать". Только от таких речей пахнет канифолью и плановой экономикой.
Рыночек сам порешает, кто из вендоров останется в каком сегменте, и даже если это не дай бох будут китайский вендоры, так уж и быть, мы проиграли технологическую гонку по неважно каким причинам, но надо иметь храбрость это признать.
c0r3dump
09.07.2024 08:32А почему нет конкретных примеров проблем с которыми вы столкнулись? Сложно понять мне, как на работу вашего OCR приложения будет влиять версия openssh и nginx в разных дистрибутивах. Или что вы такое в OCR приложении вызывает из glibc что прям так сильно поменялось, что ломает работу? Это при том, что у вас QT там, вы реально так зависите от версии glibc? Может у меня опыта мало, ocr-ов не писал, но почему-то трудно верится.
Просто ещё странно наблюдать как разработчики открытого и бесплатного софта с решением этих проблем справляются, а тут не удаётся. И правда интересно, что конкретно у вас от glibc ломается или от версии libreoffice. Вам же вообще не обязательно по идее линковаться с ним. Главное генерить формат, как это попало в зависимости?
Anton_Menshov
Советую резать острой бритвой отечественные операционные системы. Или продолжать колоться об их щетину. Некоторым нравится.
Kamnevn Автор
Сарказм понятен, но выбирать не приходится. Отечественные операционные системы, как минимум для критической инфраструктуры, государственной власти и компаний с госучастием - реальность нового времени.