Comments 15
Советую резать острой бритвой отечественные операционные системы. Или продолжать колоться об их щетину. Некоторым нравится.
Менять подход надо.
Для актуального дистрибутива выкладываем обычный бинарь или пакет. Для всяких динозавров типа астры - линкуем всё статически, а то, что бинарь большой на выхлопе - так терпите - вы же сами используете дистрибутив, пакеты которого выпущены при палеолите!
Сейчас сам столкнулся с разработкой под астру, и после многочисленных совещаний избрали именно такой подход. Да, он противоречит самой концепции линуксов, но что поделаешь - суровая реальнось диктует свои правила...
Вы действительно думаете, что статически собранный бинарь будет работать без учета версии libc и ядра не той системы? Если повезет - то будет, но чаще всего не везет :)
Уже ответили в комментах ниже. Пакеты в формате AppImage или flatpak
Всё, кроме ядра, линкуется статически. Не всегда просто, но реально. Ядро имеет довольно консервативное API, потому что-то сломать даже между мажорами - надо постараться.
В случае проблем совместимости с ядром два пути - говорим заказчику, что надобно обновление, либо за дополнительный прайс временно пересаживаем разработчиков в нужную операционку на виртуалке. Либо третий вариант - AppImage или flatpak, да, это самый жирный вариант (и чуть проблемный при обновлении), но он же и самый рабочий.
В реалиях современного российского рынка очень странно не тестировать на всех ос, что есть в списке отечественного ПО или как-там он называется. А если уж тестировать работу на них, то странно и пакеты не собрать для них.
У меня есть мысль и я её думаю
Кстати, актуальная в мире версия Python - 3.12.4, но это так, к слову, то ли иллюстрирует проблему, то ли нет...
Неконтролируемое разнообразие - не проблема, ибо разнообразие то контролируемое - лишнее отмирает само. Могло бы отмирать быстрее и от этого стало бы лучше, или ещё как-то явнее контролироваться - да, конечно, но на проблему это не тянет. Ибо если свести разнообразие к минимуму, то остановится развитие, что и отличает баг от фичи.
Скорее проблема в том, что raison d'être приложения - обеспечить знающим и умелым удобство дойки безграмотеых и криворуких, но платёжеспособных. При всей распространённости обычая, Линукс не вполне именно про это. Я ещё помню время, когда ценным результатом работы программиста был алгоритм, совсем не обязательно закодированный, а просто результатом - библиотека. Те времена не отмерли окончательно, Julia и Racket, например, вполне себе бодрячком.
Я вижу как предлагаются решения. Flatpack и AppImage используются и во многих случаях работают. Docker решает ту же проблему и тоже иногда работает. И недавно, когда обнаружился juliaup, я заприметил слона - модное приложение разбирается со своим окружением само. А ведь масса примеров была, что npm что rustup, что pip с его (в хорошем смысле) колёсами. И только Джулия произвела должное впечатление, наверно потому, что относительно недавно, да и известно что люди там сколь занятые, столь и немногочисленные.
Видел как на практике работают два приёма борьюы со вторым корнем проблемы - заказчиком. Если не тыкать его мордой, то он никогда не поинтересуется что и как там внутри обновляется - фигуры умолчания эффективны за пределами самого дикого воображения, спасибо люди добрые показали, сам бы точно не сообразил за сложностью в такое поверить. Искусно составленная смета, где напротив, много чего видно из заслуживающего обсуждения, тоже мощная штука, особенно когда хватает актёрского таланта на околофинальное "но помилуйте, если мы этого не сделаем, то вам придётся не только открыть терминал, но и ввести две команды!!!"
Суровая правда в том что это не российские разработчики ОС какие-то не такие, это десктоп на Линуксе таков какой он есть. Его достоинства перевешивают недостатки для участников рынка. Скорость и цена разработки библиотек важнее удобства использования для прикладных программистов. На совместимость компонентов все забили. Посмотрите, к примеру, что творит "Корпорация Добра". Нет совместимости ни вверх ни в низ. Интерфейсы переписываются в минорных версиях.
Отсюда нужно воспринимать это всё как данность и использовать, как выше написали, Flatpack и прочие подобные инструменты. Не должно вызывать изжоги использование в вашем проекте даже нескольких версий libc и нескольких версий компиляторов.
Всё это не так сложно если иметь культуру разработки. Можно высвободить разработчиков от этой рутины. Сервера могут собирать весь зоопарк сборок самостоятельно. Задачами портирования и совместимости должны заниматься выделенные сотрудники. В этом случае можно не терять время на скорости разработки.
Да, сопровождение софта в Linux это жесть. Если твоя программа зависит от чего-то большего, чем ядро+glibc, то без постоянного допиливания она скорее всего перестанет работать уже через 2-3 года.
Не понимаю сути мышления "давайте зарегулируем сегмент рынка любым доступным образом", чтобы развиваться смогли только сильнейшие, у кого уже есть база. Эта "база" им упала с неба в виде законодательства, а не они проведи отдичную работу, чтобы стать лидерами. Нет, мысль конечно понятная, протекционистская... Касперская тоже любит говорить "дорогое государство, а зарегулируйте нам пожалуйста инфобез, а то там так много новых игроков развелось, мы стали меньше зарабатывать". Только от таких речей пахнет канифолью и плановой экономикой.
Рыночек сам порешает, кто из вендоров останется в каком сегменте, и даже если это не дай бох будут китайский вендоры, так уж и быть, мы проиграли технологическую гонку по неважно каким причинам, но надо иметь храбрость это признать.
А почему нет конкретных примеров проблем с которыми вы столкнулись? Сложно понять мне, как на работу вашего OCR приложения будет влиять версия openssh и nginx в разных дистрибутивах. Или что вы такое в OCR приложении вызывает из glibc что прям так сильно поменялось, что ломает работу? Это при том, что у вас QT там, вы реально так зависите от версии glibc? Может у меня опыта мало, ocr-ов не писал, но почему-то трудно верится.
Просто ещё странно наблюдать как разработчики открытого и бесплатного софта с решением этих проблем справляются, а тут не удаётся. И правда интересно, что конкретно у вас от glibc ломается или от версии libreoffice. Вам же вообще не обязательно по идее линковаться с ним. Главное генерить формат, как это попало в зависимости?
Пажжити, а как же на Windows:Эта версия MS SQL сервер работает на такой-то и на такой-то версии ОС. Точка. И ничего, все как-то живут.
Взгляд некомпетентного со стороны: вы пытаетесь угодить покупателям говна. Да, я называю вещи своими именами: в 2024 году дистрибутив ОС с бесплатным ядром и открытым кодом, у которого все библиотеки статически линкованы и утилиты управления пакетами выпилены из дистрибутива во избежание его обновления (привет, Iva OS) - говно. Не говно они только в одном случае: когда собраны именно вами из исходников, на ваших мощностях для ваших целей, а не куплены за оверпрайс, потому что другого варианта вам не оставили. Но если сами ОС из исходников собрали, то и софт соберут.
Проблемы у вас не с разработкой, для решения проблем версионности библиотек уже сто лет как докер сотоварищи используется. Проблемы с покупателями говна, которые по печальному совпадению являются вашими клиентами. В ответ на это могу посоветовать только одно: продавать свой софт в составе вашего дистрибутива. Естественно, платного. Как вы там внутри и какими гвоздями будете приколачивать - это уже ваше дело. Вы просто решите проблему зоопарка, притом чужого.
Господа, не кидайтесь вы в меня тряпками, прошу, они плохо пахнут. Я понимаю, что оверхед на виртуализацию гораздо выше оного для контейнеризации, но если клиент сам себе злой Буратино - ваша ли это вина? Если дистрибутивы настолько хороши, что стоят денег и не могут в контейнеры, то это вас не волнует и не сношает. Ваше дело - деньги делать, а не загонять самих себя в dll hell, из которого программисты выбрались в контейнеры.
Спасибо за "могу посоветовать только одно: продавать свой софт в составе вашего дистрибутива. Естественно, платного. Как вы там внутри и какими гвоздями будете приколачивать - это уже ваше дело. Вы просто решите проблему зоопарка, притом чужого" - это по многим направляющим универсальный совет, к этому стоит стремиться.
Версии, библиотеки, совместимость: какие ещё проблемы я вижу в разработке под Linux