Привет, Хабр! Меня зовут Олег Ивченков, и я управляю группой компаний 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 или «облака» для основных заказчиков — государственных компаний или объектов критической инфраструктуры — не вариант, так как в первую очередь по причине ИБ‑составляющей не у всех есть возможность такие версии продуктов использовать.
Проблема шире и сейчас проявляется в самых формах и с неожиданной стороны. Например, вот в своем интервью гендиректор «Группы Астра» Илья Сивцев говорит о ландшафте рынка ИТ-продуктов и схожей проблеме многообразия. Кроме того, я читал много публикаций о проблеме количества сценариев в учебных программах и программах ИТ-наставничества. Темы разные, но боль-то схожая: любые нерегулируемые сущности стремятся заполонить собой весь объем и даже «с горкой». Бритва Оккама нужна и срочно, а — по какому принципу резать? Если резать вообще.
Заключение
Коллеги, что мы будем делать со всем этим многообразием? Своими силами решения я пока не нашел, хотя мысли есть: один из технически возможных вариантов – сокращение технологического разрыва между вендорами ОС (по поддерживаемым технологиям разрыв не такой и большой); другой — движение в сторону создания собственной ассоциации производителей нативного ПО и фреймворка. По последнему варианту намерены идти и уже есть первые результаты (о них тоже планирую со временем рассказать).
Буду рад услышать ваши соображения по изложенному в комментариях. Спасибо!