Здравствуйте, sharpcoder, Вы писали:

S>Что я вам скажу. Под MS реально проще! Там все стандартизировано, а тут куча продуктов, куча дистрибутивов линукса, абсолютный зоопарк всяких решений для кластеризации и безопасности. Все это банально настроить даже, чтобы ничего не падало — уже проблема. Админ (девопс) по факту нужен с очень большим опытом и кругозором в этом зоопарке. Сис. инженер под винду обычно знает пяток продукто — AD, MSSQL, Exchange, ну и всякие кластерные технологии и все. А тут необходимый набор знаний — ощутимо выше. Особенно "радует" разбираться в ошибках, возникающих в тех или иных решениях, собранные в уникальный для конкретного клиента зоопарк.

S>В общем, администрировать линукс реально дороже, чем винду. В этом плане мелкософт правду говорил.

Всё именно так. Это одна из причин, почему линух так медленно взлетает.
Фактически он взлетает только потому, что Микрософт с каждым днем Windows делает всё хуже и хуже.
А в линухе зоопарк дистров, жуть с glibc и еще всякого по мелочи.

Здравствуйте, sergey2b, Вы писали:

s> расскажи как одиночка может заработать под linux

Там столько возможностей, что без хлеба с маслом может оставаться только вообще ничего не делающий

Здравствуйте, sharpcoder, Вы писали:


S>В общем через боль идем на Linux. Тяжело, но мы справимся

	Скрытый текст

Здравствуйте, sergey2b, Вы писали:

S>расскажи как одиночка может заработать под linux
Точно также как под Windows, MacOS, Android и т.п.

Здравствуйте, Артём, Вы писали:

S>>В общем, администрировать линукс реально дороже, чем винду. В этом плане мелкософт правду говорил.

Аё>Микрософт сам использует линукс на бэке Потому, что венда — говно. По инерции катится на десктопах.

А чего бы им и не использовать линукс, если они его купили в него вливают деньги вот уже 25 лет?

Все проблемы от жадности и глупости

Здравствуйте, pva, Вы писали:

pva>Да понятно что нужно делать, но я просто указал на то что проблема зависимостей в линуксах стоит острее.
Ваши аргументы это никак не показывают. Если для зависимостей есть готовые пакеты, то все вообще очень просто.
Вот для примера кусок CMake кода который собирает debian пакет:

set(DEPENDENCIES
    "libgfortran5"
    "liblapack3"
    "libgpiod-dev"
    "libqt5core5a"
    "libqt5network5"
    "libqt5charts5"
    "libqt5datavisualization5"
    "libqt5quick5"
    "libqt5widgets5"
    ...
)

string(REPLACE ";" "," DEPENDENCIES  "${DEPENDENCIES}")

set(CPACK_DEBIAN_PACKAGE_DEPENDS ${DEPENDENCIES})

Попробуйте тоже самое под винду сделать.

pva>А при попытках вкомпилить рантайм в либу начинаются другие приколы, наподобие того что некоторые зависимые либы не умеют в статику и требуют только динамику.
RPATH

pva>Про АПИ ОС речи нет. Речь о том что в линуксах две соседних версии могут быть несовместимы.
Если вы говорите "в линуксах" это значит ядро. Привидите примеры где АПИ ядра ломало обратную совместимость. Отдельные дистрибутивы, наверное, могут сделать что-то сильно странное, но и это редкость.

pva>А на свежих версиях так вообще может не быть нужных пакетов еще.
Гарантии наличия пакетов нет и не должно быть. Нужные пакеты должны быть указаны в зависимостях программы и устанвливаться по необходимости.

pva>В винде редисты ставят потому что ты не знаешь до тебя поставил их кто-то или нет.
Я бы сформулировал так: собранное MSVC с настройками по умолчанию приложение требует установки дополнительных библиотек и на "чистой" ОС не заработает без них.

pva>Так-то они одни для всех и на обновляющейся винде есть свежие.
Очень часто разрабочики не устанавливают их глобально c помощью установщика от MS, т.к. это может привести к перезагре ОС, что ухудшает UX.

И да, под линуху можно делать AppImage.

Здравствуйте, DiPaolo, Вы писали:

DP>Ну да. Потому принято делать сборки под каждую таргет ОСь, типа:
DP>Ubuntu 20.04
DP>Ubuntu 22.04
Зачем? Собранное на Ubuntu 20.04 с очень высокой вероятностью будет работать на Ubuntu 22.04. Могу вообразить проблемы только если зависимости имеют разные имена или недоступны в разных версиях.

DP>Свой glibc я лично предпочитаю не носить для надежности и безгеморности.
А в чем проблема с надежностью может быть?

DP>Ах да! Еще же разные архитектуры... ну, там, x86, x64, ARM и прочее
+1
Матрица сборки штука сложная.

S>Зачем? Собранное на Ubuntu 20.04 с очень высокой вероятностью будет работать на Ubuntu 22.04. Могу вообразить проблемы только если зависимости имеют разные имена или недоступны в разных версиях.

DP>>Свой glibc я лично предпочитаю не носить для надежности и безгеморности.
S>А в чем проблема с надежностью может быть?

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

Здравствуйте, Артём, Вы писали:

S>>В общем, администрировать линукс реально дороже, чем винду. В этом плане мелкософт правду говорил.

Аё>Микрософт сам использует линукс на бэке Потому, что венда — говно. По инерции катится на десктопах.

MS развивает линукс для облаков. Не потому, что венда — говно, а потому, что контейнеры проще и дешевле под линукс.

А вот линукс для десктопа — говно!

Здравствуйте, Skorodum, Вы писали:

S>Ваши аргументы это никак не показывают. Если для зависимостей есть готовые пакеты, то все вообще очень просто.
Нет смысла спорить. Я поделился своим опытом и впечатлениями. Возможно, он недостаточно релевантен и моего опыта просто не хватает.

S>Попробуйте тоже самое под винду сделать.
Под винду тоже есть cmake и тоже умеет если научить.

pva>>А при попытках вкомпилить рантайм в либу начинаются другие приколы, наподобие того что некоторые зависимые либы не умеют в статику и требуют только динамику.
S>RPATH
Что RPATH?

pva>>Про АПИ ОС речи нет. Речь о том что в линуксах две соседних версии могут быть несовместимы.
S>Если вы говорите "в линуксах" это значит ядро.
Нет, это не значит "ядро". Это значит все окружение, включая какие-нибудь glibc и иже с ними. И не всегда возможно затащить рантайм в ОС, потому что это иногда приводит к куче конфликтов или начинает вылазить в другом софте.

pva>>А на свежих версиях так вообще может не быть нужных пакетов еще.
S>Гарантии наличия пакетов нет и не должно быть. Нужные пакеты должны быть указаны в зависимостях программы и устанвливаться по необходимости.
Я писал о том что этих зависимостей может не быть в репо для свежих ОС. Ну вот не успел автор еще портировать.
С чем-то подобным сталкивался при переходе на убунту 22, когда на серваке не было какого-то стандартного пакета.

pva>>В винде редисты ставят потому что ты не знаешь до тебя поставил их кто-то или нет.
S>Я бы сформулировал так: собранное MSVC с настройками по умолчанию приложение требует установки дополнительных библиотек и на "чистой" ОС не заработает без них.
Честно говоря, давно не проверял. По идее на обновляемой ОС, даже чистой, свежий рантайм должен быть в наличии.

S>И да, под линуху можно делать AppImage.
Может и так. Я не знаком настолько с линухами.

В общем, раз нет проблем — я рад. Значит топикстартер (как и я) не умеет готовить этого кота.

Здравствуйте, bnk, Вы писали:

bnk>·>This was a triumph. I'm making a note here: "Huge success".
bnk>Вроде же great success, а не huge
Из Still Alive же.

bnk>Image: 2024_09_03_22_21_44_image.png
Хых, я ещё не смотрел...

Здравствуйте, pva, Вы писали:

pva>Нет смысла спорить.
Для этого форум

pva>Под винду тоже есть cmake и тоже умеет если научить.
Создавать инсталятор работает с пакетным менеджером? Конечно можно, как только пакетный менеджер под винду появиться.

pva>Что RPATH?
RPATH решает указанную проблему: позволяет установить свои версии библиотек и использовать именно их. Этот параметр говорит загрузчику динамических библиотек где их дополнительно искать.

pva>Нет, это не значит "ядро". Это значит все окружение, включая какие-нибудь glibc и иже с ними.
С точки зрения приложения версии ядра и glibc совершенно ортогональны.

pva>И не всегда возможно затащить рантайм в ОС, потому что это иногда приводит к куче конфликтов или начинает вылазить в другом софте.
Конечно так делать не нужно. Своя специфичная версия glibc устанавливается куда-то вроде /opt/my-company/my-app/libs, в приложении указывается RPATH в духе $ORIGIN/../lib. И все, никаких конфликтов и проблем.

pva>Я писал о том что этих зависимостей может не быть в репо для свежих ОС. Ну вот не успел автор еще портировать.
Это исключение. Мы же про то и говорим, что в общем случае в линухе явно портировать "вперед" нет необходимости.

pva>Честно говоря, давно не проверял. По идее на обновляемой ОС, даже чистой, свежий рантайм должен быть в наличии.
Почему он там должен быть? MS где-то такое обещало?
На 110% уверен, что нет, но вот самый простой способ проверить.

S>>И да, под линуху можно делать AppImage.
pva>Может и так. Я не знаком настолько с линухами.
А мне надо поддерживать сборку под разные платформы.

pva>В общем, раз нет проблем — я рад. Значит топикстартер (как и я) не умеет готовить этого кота.
Зато топик стартер умеет софт продавать

А можно примеры пожалуйста
А то я пилил для нескольких open source проектов
И денег не видел

Здравствуйте, Stanislaw K, Вы писали:

SK>А чего бы им и не использовать линукс, если они его купили в него вливают деньги вот уже 25 лет?

Xenix Initial release: 1980; 44 years ago

Здравствуйте, sharpcoder, Вы писали:


S>Произвели миграцию нашего флагманского продукта на opnesource стэк разработки, теперь это все работает на линуксе и постгриsql. Ну и всякие апачи, докеры, куберы, и прочее опенсорсное.

S>Что я вам скажу. Под MS реально проще! Там все стандартизировано, а тут куча продуктов, куча дистрибутивов линукса, абсолютный зоопарк всяких решений для

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

Здравствуйте, sergey2b, Вы писали:


SK>>А чего бы им и не использовать линукс, если они его купили в него вливают деньги вот уже 25 лет?

S>Xenix Initial release: 1980; 44 years ago

да, но нет. с 1999 года (а возможно и раньше) они спонсируют именно современный Linux от Торвальдса. все эти ранние неуклюжие "FSF" "OSI" "OSD" и нынешнюю "The Linux Foundation" (где они прочно в первой тройке платиновых партнеров (что определяется по сумме заноса)).

Все проблемы от жадности и глупости

Здравствуйте, DiPaolo, Вы писали:

DP>Очень любопытно (без до^ба, в прямом смысле).
DP>А какой был/стал стек? Если можно поделиться.
DP>Ну вот тот же докер и кубер чем заменить на Винде? Это ж кроссплатформа. Апач тоже весь стек под винду есть.

Вы лучше скажите, на кой чёрт вам нужен докер. Хотя я знаю — чтобы не делать нормальное пакетирование.

А ещё лучше так: чтобы образ докера при старте скачивал код с гитхаба, собирал его и запускал.

Тьфу. Правильно тут пишут при msi.

С>Вы лучше скажите, на кой чёрт вам нужен докер. Хотя я знаю — чтобы не делать нормальное пакетирование.

Спокойно! Без паники! Я не фанат докера и использование докера ради докера Если можно без него – предпочитаю без него. Если он полезен (вопсроизводимое окружение, легкость поднятия, простое масштабирование и прочие ништяки) – юзаю его.

Здравствуйте, DiPaolo, Вы писали:

DP>Свой glibc я лично предпочитаю не носить для надежности и безгеморности.

А главное — зачем таскать с собой libc (кроме экстренных случаев; под экстренными случаями понимается ситуация, когда либа, которую необходимо использовать, присутствует только в бинарном виде и собрана с более новой версией libc, чем та, которая есть в целевой системе)? libc, как уже коллега Skorodum упомянул, имеет обратную совместимость, и то, что собрано, прекрасно будет работать в более новых версиях той же системы (собранное в Debian 9 работает в 10, 11, Астре — это тот вариант, который был проверен практически, надо бы, ради интереса, попробовать запустить на Ubuntu), если с собой притащено всё остальное, что требуется.
P.S. В частности, linuxdeployqt — один из возможных инструментов для формирования self-contained (и для не Qt-проектов), с учётом нашей специфики пару правок внесли — вообще горя не знаем.

Здравствуйте, sergey2b, Вы писали:

S>А то я пилил для нескольких open source проектов
S>И денег не видел

А если б ты пилил для open source проектов под Виндовс, то бабло мешками что ль сыпалось бы? (риторический вопрос, если что)