Если вам очень дорог клиент, то вы можете конечно выпустить ПО именно под его окружение, но это совсем другая история.
Я и пытаюсь донести, что разработка коммерческого софта под linux — это почти всё время какая-то «другая история». Вместо решения задач предметной области приходится тратить много ресурсов на преодоление побочек от unix way.
Нету вообще никаких проблем c GPL
Пробемы чисто техническая. Даже на LTS системах поддержа продолжается годами, но новые glibc не поставляются. В итоге мой компилер в centos линкует к моей проге системную glibc2.13. А где-то «продвинутые» разработчики юзают 2.23. И мне её взять негде.
специально собирал тот же curl, который будучи собранным на Ubuntu18, отлично запускается на Ubuntu 14-20/Debian 8-10, CentOS/RHEL 6-8 и даже alpine, хотя там вообще нет glibc. Так что вопрос совместимости очень не однозначный
Ну так это вы сами собирали. Если мне достался коммерческий компонент, собраный кем-то, мне его никто собрать не даст. И обеспечить совместимость крайне затруднительно, потому что никто этой совместимостью особо не озабочен.
Вот вы смешные. Думаете, что дело в том, что я не умею загрузить либу из кастомной директории. Проблема в другом. Либы нет. НЕТ. Да её можно собрать руками, что само по себе квест. И положить куда надо. И загрузить. И даже будет работать. Я даже так делал. Куда деваться-то. НО. Кто даст гарантию, что ядро кастомера совпадет с тем, что у меня? Особенно если кастомер через полгода обновится? А glibc завязана на ядро. Да, там есть гарантии, что новая glibc будет работать на более старом ядре. А наоборот — нет гарантий.
А в винде я просто копирую 2-3 дллки в папку с прогой. Всё.
Код недоступен, кодек куплен у стороннего поставщика.
Статически линковать glibc — а где его взять? Линковать glibc плохая идея, по нескольким причинам — во-первых glibc зависит от ядра, во-вторых даже при статической линковке загрузчик загружает динамическую версию (непомню для чего). Вобщем -моветон и опасный.
переопределить местоположение библиотек через LD_PRELOAD?
Отсутстствие этой самой библиотеки. Ну вот нет под центос 6.x готовой glibc 2.23.
ПО писанное для windows XP спокойно работает на Windows 10.
K-Lite Codec pack это просто сборка кривых поделок написаных кое-как. Сама ОС тут не причём.
разрабатываешь под EOL ОС — готовься к проблемам
Вобще-то у centos 6 поддержка закончилась недавно — в ноябре 2020.
В том-то и дело, что нет. У меня на личном сайте висят shareware программки, разработку которых я забросил в 2008 году. Прекрасно запускаются на 10ке. И наоборот я могу сделать проект для XP, просто поставлю на 10ку старую студию и всё.
Что до задушевных бесед с заказчиками — беседы были, но закончились ничем. Это серьезные люди, которые не бросаются апгрейдить сотню своих станций молотящих в продакшне 24/7 только чтобы сделать мне удобнее. Там много чего приходится поддерживать, например, приходится поставлять компоненты собранные в двух вариантах — под AVX2 и под SSE4 only, потому что часть станций это старые сервера без AVX.
Я пишу библиотеки и конечные приложения для обработки видео. Так вот, как ОС для рабочей станции линукс не очень ОК. К примеру, если мне нужен кодек для моего транскодера под windows я просто беру библиотеку и линкую. Если транскодер пишется под linux, я должен сначала спросить у клиента, а какой именно у него линукс. Потому что часто бывает, что SDK собран под новой модной убунтой, а у клиента какой-нибудь centos 6.x и нужно все пересобирать под старой glibc. Просто приложить старый рантайм, как в windows, невозможно. При этом может оказаться что «кодека под старый линукс» у нас просто нет.
В итоге оказывается, что нужно держать у себя несколько десктопов — для этого клиента — древний centos, а для этого, наоборот, новый ubuntu, потому что, в древнем центосе нет свежего gstreamer в репозиториях.
При этом возникает проблема с GUI-программами для разработки, только привык к чему-то на одной платформе, как оказывается, что в новой версии эта тулза отстутствует и собрать руками её толком нельзя, потому что там куча зависимостей. Из того, что реально выбесило — потеря RapidSVN и GnomeCommander.
Одни и теже тулзы на разных сборках могут работать по-разному — я сталкивался с тем, что для сборки gstreamer на ubuntu и на centos нужно использовать разные скрипты, хотя исходники одни и теже — просто autotools по разному работают.
Или вот прикол — как раз из разряда «поэксперементировать». Захотел себе VisualStudioCode под CentOs 6.x Ну официально не ставится, но можно как-то там пропатчить. Пропатчил. В итоге там поменялись системные библиотеке и у клиента перестал запускаться транскодер. Пришлось откатывать (что само по себ ещё тот квест). Иногда подобные «эксперименты» заканчивались перестановкой системы, поэтому я стараюсь на своих линуксовых машинах ничего не трогать и даже код редактирую в gedit.
Вобщем, я согласен с авторами статьи — как десктоп линукс очень плох.
Возможно, там действительно лучше медицина — в плане профилактики. Во всяком случае, год назад, во время первой волны уже показывали пальцами на Германию, писали, что они делают больше тестов и всякое такое: www.bbc.com/russian/features-52191093
Если пытаться объяснять без привлечения теории заговора, то можно выдвинуть такую гипотезу — в Европе в первую волну умерло очень много пожилых людей — целые дома престарелых вымирали. Во вторую волну по понятным причинам таких случаев было сильно меньше, а диагностика, наоборот, улучшилась.
НО. если посмотреть общую смертность в Европе, то окажется, что есть две волны вполне себе сопоставимые по размерам. То есть очень похоже, на мухлеж со статистикой. Вполне возможно, что в первую волну чило смертей от ковида искусственно завышали, а во вторую занижали.
Посмотрите на графики здесь: www.euromomo.eu/graphs-and-maps
За индивидуальный график IgG отдельное спасибо, познавательно.
Я и пытаюсь донести, что разработка коммерческого софта под linux — это почти всё время какая-то «другая история». Вместо решения задач предметной области приходится тратить много ресурсов на преодоление побочек от unix way.
Во-первых stackoverflow.com/questions/57476533/why-is-statically-linking-glibc-discouraged
А во-втрорых статическая линковка не решает проблему совместимости. Линкуя glibc статически вы фактически статически линкуетесь к к конкретной версии ядра. Со всеми вытекающими.
Пробемы чисто техническая. Даже на LTS системах поддержа продолжается годами, но новые glibc не поставляются. В итоге мой компилер в centos линкует к моей проге системную glibc2.13. А где-то «продвинутые» разработчики юзают 2.23. И мне её взять негде.
Ну так это вы сами собирали. Если мне достался коммерческий компонент, собраный кем-то, мне его никто собрать не даст. И обеспечить совместимость крайне затруднительно, потому что никто этой совместимостью особо не озабочен.
А в винде я просто копирую 2-3 дллки в папку с прогой. Всё.
Статически линковать glibc — а где его взять? Линковать glibc плохая идея, по нескольким причинам — во-первых glibc зависит от ядра, во-вторых даже при статической линковке загрузчик загружает динамическую версию (непомню для чего). Вобщем -моветон и опасный.
Отсутстствие этой самой библиотеки. Ну вот нет под центос 6.x готовой glibc 2.23.
K-Lite Codec pack это просто сборка кривых поделок написаных кое-как. Сама ОС тут не причём.
Вобще-то у centos 6 поддержка закончилась недавно — в ноябре 2020.
Что до задушевных бесед с заказчиками — беседы были, но закончились ничем. Это серьезные люди, которые не бросаются апгрейдить сотню своих станций молотящих в продакшне 24/7 только чтобы сделать мне удобнее. Там много чего приходится поддерживать, например, приходится поставлять компоненты собранные в двух вариантах — под AVX2 и под SSE4 only, потому что часть станций это старые сервера без AVX.
В итоге оказывается, что нужно держать у себя несколько десктопов — для этого клиента — древний centos, а для этого, наоборот, новый ubuntu, потому что, в древнем центосе нет свежего gstreamer в репозиториях.
При этом возникает проблема с GUI-программами для разработки, только привык к чему-то на одной платформе, как оказывается, что в новой версии эта тулза отстутствует и собрать руками её толком нельзя, потому что там куча зависимостей. Из того, что реально выбесило — потеря RapidSVN и GnomeCommander.
Одни и теже тулзы на разных сборках могут работать по-разному — я сталкивался с тем, что для сборки gstreamer на ubuntu и на centos нужно использовать разные скрипты, хотя исходники одни и теже — просто autotools по разному работают.
Или вот прикол — как раз из разряда «поэксперементировать». Захотел себе VisualStudioCode под CentOs 6.x Ну официально не ставится, но можно как-то там пропатчить. Пропатчил. В итоге там поменялись системные библиотеке и у клиента перестал запускаться транскодер. Пришлось откатывать (что само по себ ещё тот квест). Иногда подобные «эксперименты» заканчивались перестановкой системы, поэтому я стараюсь на своих линуксовых машинах ничего не трогать и даже код редактирую в gedit.
Вобщем, я согласен с авторами статьи — как десктоп линукс очень плох.
В самсунгах есть knox, где по умолчанию всё свое, в том числе и список контактов. Заодно и лишний уровень защиты при краже телефона.
www.bbc.com/russian/features-52191093
НО. если посмотреть общую смертность в Европе, то окажется, что есть две волны вполне себе сопоставимые по размерам. То есть очень похоже, на мухлеж со статистикой. Вполне возможно, что в первую волну чило смертей от ковида искусственно завышали, а во вторую занижали.
Посмотрите на графики здесь:
www.euromomo.eu/graphs-and-maps
За индивидуальный график IgG отдельное спасибо, познавательно.