Здравствуйте, Sharov, Вы писали: S>Core же, или у Вас винформс? Вроде и его сделали кроссплатформенным?
.Net Framework с Winforms GUI компонентами сторонними.
Все дело упирается в отсутствие нормального кроссплатформенного GUI.
Здравствуйте, Unhandled_Exception, Вы писали:
U_E>Всем привет,
U_E>Конечно, это может быть ошибкой писать именно в этот раздел, но тем не менее.
У тебя девелоперская либо которая используется с при разработке или как это выглядит? Можно попробовать докер если позволяет приложение.
U_E>Смущает только один момент. Как я понимаю, нельзя просто так собрать бинарники, чтобы они везде работали. Как же быть?
Оно +- везде будет работать если отдать .so файлы. Можно собрать под LTS версии 16 и 18, и на этом остановится. По запросу пересобрать под таргет платформу. Если у тебя некая либа которая работает в отдельном процессе, то можно использовать dbus и через него общаться с тем что надо заказчику, самому же тащить все зависимость в /usr/local/lib. Если дальше идти, то ты можешь поднять свой репозиторник и аутентификацией и доступом раздвая обновления, порты на новые версии линукса +- оттуда.
U_E>Хочу спросить коллег, кто продает продукты под linux, с какими проблемами столкнулись, как собираете бинарники?
Я не продаю. В конторе просто одна ОС и та центос, но пакетируем в рпм и ставим со своего репо.
Здравствуйте, Unhandled_Exception, Вы писали:
UE> Смущает только один момент. Как я понимаю, нельзя просто так собрать бинарники, чтобы они везде работали. Как же быть?
* Распространять в исходниках (самый правильный вариант).
* Собирать статически.
Здравствуйте, Unhandled_Exception, Вы писали: U_E>Конечно, это может быть ошибкой писать именно в этот раздел, но тем не менее. U_E>Пользователи уговорили портировать продукт на linux. Начал разработку в убунте, дело вроде идет. U_E>Смущает только один момент. Как я понимаю, нельзя просто так собрать бинарники, чтобы они везде работали. Как же быть? U_E>Хочу спросить коллег, кто продает продукты под linux, с какими проблемами столкнулись, как собираете бинарники?
У нас несколько продуктов кросс-платформены и собираются в тч под линух, например порт маппер.
В целом жить можно, используется Lazarus в кач-ве среды разработки. Проблемы бывают разные, например только привязались к openssl1.0.0, его выкидывают из последней убунты и поставить из репо нельзя — только openssl1.1.0. Отдельный геморой с иконкой в трее, на каких-то DE это работает, на каких-то нет.
Другое дело что хз сколько там среди них покупателей, если портировать на что-то кроме винды, то имеет смысл начинать с macOS — там больше денег, юзеров и нет зоопарка дистрибутивов.
Здравствуйте, Unhandled_Exception, Вы писали:
UE> Смущает только один момент. Как я понимаю, нельзя просто так собрать бинарники, чтобы они везде работали. Как же быть?
Здравствуйте, Unhandled_Exception, Вы писали:
U_E>Хочу спросить коллег, кто продает продукты под linux, с какими проблемами столкнулись, как собираете бинарники?
Здравствуйте, Nonmanual Worker, Вы писали:
S>>Core же, или у Вас винформс? Вроде и его сделали кроссплатформенным? NW>.Net Framework с Winforms GUI компонентами сторонними. NW>Все дело упирается в отсутствие нормального кроссплатформенного GUI.
Mono работает, если нет сторонних компонентов. Я даже проверил, и даже работает, другое дело, что продавать не стал, по крайней мере пока.
Масса достоинств:
1) кросплатформенность
2) работает на Android
3) тяжело выкопировать из приложения контент
4) часть логики можно оставить на сервере
5) готовые рынки приложений для монетизации
Здравствуйте, Kernan, Вы писали:
U_E>>Смущает только один момент. Как я понимаю, нельзя просто так собрать бинарники, чтобы они везде работали. Как же быть? K>Оно +- везде будет работать если отдать .so файлы. Можно собрать под LTS версии 16 и 18, и на этом остановится.
Пытаюсь понять, как это работает. Так-то я под виндой всю жизнь сидел. Как я понимаю, .so это вроде DLL-ек. По идее надо так собрать все бинарники, чтобы они использовали те *.so, которые есть на клиентской машине.
Здравствуйте, Черный Властелин, Вы писали:
ЧВ>В целом жить можно, используется Lazarus в кач-ве среды разработки.
Я на С++, так что взял vscode. А для UI думаю взять electron, но пока до UI не дошел.
ЧВ>Проблемы бывают разные, например только привязались к openssl1.0.0
А нельзя ее таскать с собой, как мы бы это делали под виндой?
ЧВ>Другое дело что хз сколько там среди них покупателей, если портировать на что-то кроме винды, то имеет смысл начинать с macOS — там больше денег, юзеров и нет зоопарка дистрибутивов.
У меня продукт для разработчиков, для маков запросов вообще не было.
Здравствуйте, Unhandled_Exception, Вы писали:
UE> Пытаюсь понять, как это работает. Так-то я под виндой всю жизнь сидел. Как я понимаю, .so это вроде DLL-ек. По идее надо так собрать все бинарники, чтобы они использовали те *.so, которые есть на клиентской машине.
Не заморачивайся с песочницами, возьми AppImage и получишь переносимый, работающий везде монолит.
Здравствуйте, rudzuk, Вы писали:
R>Не заморачивайся с песочницами, возьми AppImage и получишь переносимый, работающий везде монолит.
У меня отладчик, который должен грузить мою *.so в отлаживаемый процесс, чтобы перехватывать функции типа malloc / free. Подозреваю, что AppImage сам перехватывает вызовы (не уверен). В принципе я уже готов отказаться от C++ в пользу обычного С, если есть гарантия, что я смогу собирать бинарники на одной машине, и это будет работать всюду (или почти всюду).
Здравствуйте, Unhandled_Exception, Вы писали:
UE> У меня отладчик, который должен грузить мою *.so в отлаживаемый процесс, чтобы перехватывать функции типа malloc / free. Подозреваю, что AppImage сам перехватывает вызовы (не уверен). В принципе я уже готов отказаться от C++ в пользу обычного С, если есть гарантия, что я смогу собирать бинарники на одной машине, и это будет работать всюду (или почти всюду).
AppImage это просто образ squashfs монтируемый FUSE. Для юзера все прозрачно и нет задержки при запуске, как у snappy, например. Есть полный доступ к системе (snap vs AppImage).
Здравствуйте, Unhandled_Exception, Вы писали:
UE> Скажем, я могу взять gdb, который у меня сейчас на убунте, упаковать его, и он будет условно везде запускаться?..
Типа того. Образ должен содержать весь используемый рантайм.
Здравствуйте, Unhandled_Exception, Вы писали:
U_E>У меня отладчик, который должен грузить мою *.so в отлаживаемый процесс, чтобы перехватывать функции типа malloc / free. Подозреваю, что AppImage сам перехватывает вызовы (не уверен). В принципе я уже готов отказаться от C++ в пользу обычного С, если есть гарантия, что я смогу собирать бинарники на одной машине, и это будет работать всюду (или почти всюду).
Тут обычная проблема с abi break и бинарной совместимостью с libc, libstdc++ и т.п. Тебе надо динамически юзать тот же рантайм (libc) что и приложение которое подгружает твою либу. Всё как на винде, короче. Мне кажется, тебе не надо заморачиваться и просто сделать сборку под LTS 16.04/18.хх и проверить как это всё будет работать под 18.хх. На счёт того как распространять, наверное AppImage вариант, но я его не использовал. Если платформа только убунту, то просто deb пакет сделай по правилам и в репозиторник свой засунь с подписями, gpg и т.п., но тут уже я не советчик.
Здравствуйте, Unhandled_Exception, Вы писали:
U_E>уже готов отказаться от C++ в пользу обычного С, если есть гарантия, что я смогу собирать бинарники на одной машине, и это будет работать всюду (или почти всюду).
Зачем для этого отказываться от C++? Максимум — от тех особенностей, которые недостаточно поддерживаются в линуксах. Привыкнув даже к подмножеству C++, писать на C уже очень некомфортно (если это, конечно, не C11/18 или что-то подобное).
U_E>Пользователи уговорили портировать продукт на linux. Начал разработку в убунте, дело вроде идет.
U_E>Смущает только один момент. Как я понимаю, нельзя просто так собрать бинарники, чтобы они везде работали. Как же быть?
Я не твой коллега, в смысле не пишу шаревару под линукс (хотя участвовал в одном проекте), и предложу следующее. На десктопе используется не так много вариантов Linux, поэтому, для начала собери под тот дистрибутив, которым пользуешься сам и потребители, готовые заплатить. А дальше будешь разбираться, как сделать под другие дистрибутивы. Весьма вероятно, что кроме Ubuntu (последнего LTS) никакой другой дистрибутив поддерживать и не придется.
Приложение собирать с библиотеками (кроме libc) статически или с RPATH (как в винде с динамическими библиотеками в собственной папке, но в нее должен быть прописан RPATH относительно exe'шника). Это стандартный подход для коммерсантов, распространяющих только бинарники. Разные flatpack и другие докеры работают так: сначала тебе придется каждому пользователю объяснить, как установить flatpack на его дистрибутиве... Т.е. нифига не решат задачу, но создадут дополнительные трудности с установкой flatpack (который может быть не в каждом дистрибутиве). Ну, и как я сказал, дистрибутив может оказаться только один, либо пара и разница между ними небольшая.
K>Тут обычная проблема с abi break и бинарной совместимостью с libc, libstdc++ и т.п. Тебе надо динамически юзать тот же рантайм (libc) что и приложение которое подгружает твою либу.
Конкретно libc и libstdc++ очень хорошо поддерживают обратную совместимость. Т.е. каждая следующая версия libc будет работать с приложением, собранным с более старой версией libc. Т.е. обновление libc никак не сломает работу приложения, его даже пересобирать не нужно. Потому что в каждой последующей версии libc и libstdc++ находятся все более ранние версии функций в формате func_name@version, а при импорте указывается тоже имя с версией.
Кроме того, libc нельзя линковать статически, а libstdc++ обычно нет смысла. Единственная причина, когда у тебя что-то не сработает, если ты слинкуешь на машине с новой libc, а запускать будешь на старой libc, тогда требуемых функций с более новыми версиями не будет и приложение не запустится.
В общем, тема довольно большая, поэтому, я бы предложил ТС сначала собрать приложение на удобном ему дистрибутиве не заморачиваясь с библиотеками и их распространением, а затем тут задавать вопросы, которые появятся.
Здравствуйте, Masterspline, Вы писали:
M>Конкретно libc и libstdc++ очень хорошо поддерживают обратную совместимость. Т.е. каждая следующая версия libc будет работать с приложением, собранным с более старой версией libc. Т.е. обновление libc никак не сломает работу приложения, его даже пересобирать не нужно.
Как лучше всего настроить разработку в таком случае? Мне достаточно C++98. Начал работу в vscode, использую cmake, clang.
Здравствуйте, Unhandled_Exception, Вы писали:
U_E>Как лучше всего настроить разработку в таком случае? Мне достаточно C++98. Начал работу в vscode, использую cmake, clang.
Если у тебя 10 винда Про, то скачай докер контейнер убунту или построй свой и разрабатывай поверх него не занимаясь вознёй разворачиванием виртуальных машин как минимум для компиляции и автотестов, и CI если есть. Можно напрямую в виртуалке поставить убунту и под ней всё делать. В случае, если у тебя будет новая ОС, например сентос, то ты просто возьмёшь контейнер с ней и протестишь сборку/сделаешь рпм.
M>>Конкретно libc и libstdc++ очень хорошо поддерживают обратную совместимость. Т.е. каждая следующая версия libc будет работать с приложением, собранным с более старой версией libc. Т.е. обновление libc никак не сломает работу приложения, его даже пересобирать не нужно.
U_E>Как лучше всего настроить разработку в таком случае? Мне достаточно C++98. Начал работу в vscode, использую cmake, clang.
Я же написал. Сначала определи, для какого дистрибутива твои пользователи (готовые заплатить) хотят увидеть продукт. Вот под него и разрабатывай. Дальше, если потребуется приложение под другие дистрибутивы — сообразишь, как это исправить (там будут небольшие изменения). Когда нужно будет поддерживать несколько версий одного дистрибутива (LTS последний и предыдущий), тоже посмотришь, чем они отличаются и сообразишь (возможно, достаточно будет собирать под оба дистрибутива из одних исходников, а может в новом будет новая версия какой-то библиотеки, которой нет в старой, тогда, возможно, ее придется линковать статически или через RPATH). В общем вариантов много, когда столкнешься — приходи, найдем подходящее решение.
А начинать, как я уже говорил, нужно с того дистрибутива, за который тебе готовы платить (и, возможно, никакой другой и не понадобится, либо они будут совместимы бинарно, т.е. один exe'шник будет работать на всех, либо нужно будет пересобрать из тех же исходников в каком-нибудь докере под Mint свою версию, под Ubuntu свою и то, только потому, что у них libчто-то_там различается по SONAME). Уверен, ты и сам в курсе, что на словах бывает много хотелок, а заплатить готовы три пользователя и все под Ubuntu LTS, а остальные (например, Fedora и Arch) готовы только на форумах разговоры разговаривать... Когда денег предложат — тогда и будешь реагировать на их потребности.
Здравствуйте, Masterspline, Вы писали:
M>Я же написал. Сначала определи, для какого дистрибутива твои пользователи (готовые заплатить) хотят увидеть продукт. Вот под него и разрабатывай.
Вот я и хочу понять, что означает "разрабатывать под конкретный дистрибутив"
M>новая версия какой-то библиотеки
У меня код достаточно простой: С++, системные вызовы вроде mmap. Вот вывод ld:
U_E>Вот я и хочу понять, что означает "разрабатывать под конкретный дистрибутив"
Ну, представь, что Windows — это такой очень экзотичный дистрибутив Linux. Ты же под него как-то разрабатываешь. Тут все так же. Тебе нужно либо виртуалка с Linux, чтобы там все компилировать и проверять работу. Либо тут про докер писали, но я сам под виндой не работаю, поэтому про докер с Linux'ом под винду ничего не знаю.
M>>новая версия какой-то библиотеки
U_E>У меня код достаточно простой: С++, системные вызовы вроде mmap. Вот вывод ld:
U_E>
U_E>Может так статься, что где-то не будет, скажем, libpthread.so.0?..
libpthread — это часть libc. Там ситуация такая: если ты компилируешь свое приложение под одной версией libc, то использовать можешь под той же или последующими, причем под любым дистрибутивом Linux. В теории это правило можно нарушить, но я про такое не слышал ни разу. Считай, что libc есть везде. И, как я уже писал, libc можно линковать только динамически (никакой статики). libstdc++ можно статикой, там спецключи компилятора и линковщика, но сначала полезно убедиться, что это нужно. Другие библиотеки, которых нет в дистрибутиве (или их версии различаются в разных дистрибутивах, например, OpenSSL 1.1.0 и 1.0.1), можно статикой или rpath.
Но, если ты будешь вести разработку под тем же дистрибутивом, под которым будешь распространять приложение, то эти вопросы вообще задавать нет смысла.
Вообще, тема обширная, вариантов много, поэтому вопросы лучше задавать, когда с ними столкнешься. Ну и разработку нужно вести по правилам приличия. В смысле, сборка должна делаться запуском одного скрипта (make, cmake, my_own_build_script.sh). Тогда и CI будет возможен и завернуть бинарник в deb/rpm пакет получится (или flatpack/snap/AppImage, если они тебе или твоим пользователям больше понравятся).
M>>Ну, представь, что Windows — это такой очень экзотичный дистрибутив Linux.
U_E>В нем ведь нету libc.so, не считается!
Чет какой-то жесткий offtop пошел.
Во-первых, есть. Mingw не тянет с собой libc, а линкуется с виндовыми dll (libpthread, там, возможно, нет, но большая часть libc есть). Причем, именно виндовыми, а не MSVC.
Во-вторых, речь шла про организацию разработки. Она не сильно отличается от винды (по сути, а не внешнему виду). IDE, компилятор, отладчик, документация, другие инструменты, например, виртуалка с Linux, если разработка идет под виндой, а также мозг и руки. Отличие, опять же, в мелочах, которые могут сильно отвлекать с непривычки (например, в IDE другие хоткеи или непонятно где в меню искать пути к заголовками и библиотекам в QtCreator, когда хорошо известно, где они в MSVC).
Здравствуйте, Unhandled_Exception, Вы писали:
U_E>Всем привет, U_E>Конечно, это может быть ошибкой писать именно в этот раздел, но тем не менее. U_E>Пользователи уговорили портировать продукт на linux. Начал разработку в убунте, дело вроде идет. U_E>Смущает только один момент. Как я понимаю, нельзя просто так собрать бинарники, чтобы они везде работали. Как же быть? U_E>Хочу спросить коллег, кто продает продукты под linux, с какими проблемами столкнулись, как собираете бинарники? U_E>Спасибо!
Очень просто добаляете -Xlinker '-rpath=$ORIGIN/libs' и складываете туда все so.
Или LD_LIBRARY_PATH и плюс собираете под разные архитектуры i386,x64,arm,arm64
И запихиваем в deb или rpm, на крайняк в tar.gz
Для ленивых есть конечно snap. Это тоже самое но запакованное в squashfs с блекждеком и overlayfs-ом.
Альтернатива java, но есть нюансы.
Еще можно просто в wine пускать. Или вообще кросплатформенно в dosbox
Здравствуйте, Unhandled_Exception, Вы писали:
UE> Может подкинешь ссылку на мануал, что иметь в виду, какие подводные камни?
Мануала как такового нет — просто нужно все зависимости собрать как статические библиотеки (.a) и слинковать все вместе со статической версией glibc или аналога (musl например). Основная заморочка будет со сборкой зависимостей в статические библиотеки (не всегда поддерживаются авторами в пользу динамических .so). Как только есть все .a-шки сборка своего проекта будет тривиальной.
Здравствуйте, Unhandled_Exception, Вы писали: U_E>Смущает только один момент. Как я понимаю, нельзя просто так собрать бинарники, чтобы они везде работали. Как же быть?
Серверная часть, демон без интерфейса, у них работает действительно везде. На нашем микродистрибутиве, в котором от линукса одно ядро и кусочек libc, серверная часть запустилась сразу безо всяких костылей. Зависимости (после распаковки из upx):
$ldd vhusbdi386
not a dynamic executable
Статически линковано со всем. Привет тем, у кого "libc нельзя линковать статически".
Здравствуйте, Unhandled_Exception, Вы писали:
U_E>Смущает только один момент. Как я понимаю, нельзя просто так собрать бинарники, чтобы они везде работали. Как же быть?
Несколько способов:
1) Старый добрый. Берём древнюю версию Линукса (скажем, RHEL6) и собираем на ней. На нём же собираем и нужные библиотеки зависимостей. Основные библиотеки Линукса почти идеально обратно совместимы, так что древние бинарики работают на всём более новом.
2) Альтернативно добрый. Берём Alpine Linux и собираем на нём. Он позволяет статически собрать бинарик, который ни от чего вообще не зависит. Может быть неприменимо для некоторых систем.
2.5) Можно писать на Go — там по умолчанию сразу получаются статические бинарики.
3) Модерновый. Использовать flatpak или snapcraft — они позволяют собрать контейнер, в который пакуются все зависимости. Заодно у них есть и магазины: https://snapcraft.io/store
U_E>Хочу спросить коллег, кто продает продукты под linux, с какими проблемами столкнулись, как собираете бинарники?
Лично использовал все способы.
Здравствуйте, CRT, Вы писали:
CRT>Я просто адаптировал под WINE. (Было несколько моментов из-за которых не работало под вайном)
Запустил вчера свое приложение под WINE. Как не странно но заработало (у меня .Net Framework 4.5.2).
Но тупо падает и закрывается при некоторых действиях. Как искать причину непонятно.
CRT>>Я просто адаптировал под WINE. (Было несколько моментов из-за которых не работало под вайном) NW>Запустил вчера свое приложение под WINE. Как не странно но заработало (у меня .Net Framework 4.5.2). NW>Но тупо падает и закрывается при некоторых действиях. Как искать причину непонятно.
Его надо из консоли запускать, тогда он будет писать туда ошибки.
Правда, он туда кучу всего пишет, но понять можно.
Здравствуйте, CRT, Вы писали:
CRT>Его надо из консоли запускать, тогда он будет писать туда ошибки. CRT>Правда, он туда кучу всего пишет, но понять можно.
Я из консоли и запускаю, но он только одну строку неинформативную выдает при вылете.
Думал может где еще есть более детальный лог.
NW>Я из консоли и запускаю, но он только одну строку неинформативную выдает при вылете. NW>Думал может где еще есть более детальный лог.
У меня просто поток разных сообщений туда пишет. У меня были проблемы, что не все параметры некоторых API поддерживались, и он прямо туда об этом написал. Но у меня C++, WinAPI. Как с .NET — не знаю. Другая проблема была не связанна непосредственно с WINE — это был мой баг, но проявлялся он именно в WINE.
Может есть специальные параметры для более детального лога. А вообще, своя отладка, свои логи должны помочь понять, на какой именно строке кода валится программа.
Здравствуйте, Unhandled_Exception, Вы писали:
U_E>Всем привет,
U_E>Конечно, это может быть ошибкой писать именно в этот раздел, но тем не менее.
U_E>Пользователи уговорили портировать продукт на linux. Начал разработку в убунте, дело вроде идет.
U_E>Смущает только один момент. Как я понимаю, нельзя просто так собрать бинарники, чтобы они везде работали. Как же быть?
U_E>Хочу спросить коллег, кто продает продукты под linux, с какими проблемами столкнулись, как собираете бинарники?
U_E>Спасибо!
Берешь свой бинарник your-bin-name, запускаешь команду
ldd your-bin-name
получаешь список библиотек.
Копируешь все эти библиотеки в отдельный каталог (подразумевается что там лежит и your-bin-name) .
Запускаешь на каждую библиотеку ту же команду, смотрришь их зависимости, копируешь зависимости туда же. Повторять процесс пока новых библиотек не будет выявляться. libc.so.* скорее всего можно не копировать
Пишешь враппер на bash под названием run-my-bin.sh и кладешь ее в тот отдельный каталог
#!/bin/sh
cd "`dirname $0`"
curdir="`pwd`"
export LD_LIBRARY_PATH="${curdir}`:${LD_LIBRARY_PATH}"
exec ./your-bin-name
и заставляешь юзеров пускать run-my-bin.sh вместо your-bin-name
Если библиотекам не нужно никаких конфигов и файлов с данными (шрифты и тд) то все будет запускаться на любом линуксе с любой версией libc
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, Masterspline, Вы писали:
M>> Кроме того, libc нельзя линковать статически
AB>Можно через `gcc -static`. Можно использовать musl в качестве заменителя glibc, но будет медленнее процентов на 10.
Ага, и тогда придется выпускать свое приложение под GPL и публиковать свой исходный код всем кто получает бинарник твоего приложения
Здравствуйте, vladrsdn, Вы писали:
v> AB>Здравствуйте, Masterspline, Вы писали: v> M>> Кроме того, libc нельзя линковать статически v> AB>Можно через `gcc -static`. Можно использовать musl в качестве заменителя glibc, но будет медленнее процентов на 10. v> Ага, и тогда придется выпускать свое приложение под GPL и публиковать свой исходный код всем кто получает бинарник твоего приложения
a) musl под MIT лицензией
б) нет ничего страшного в предоставлении исходного кода.
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, Unhandled_Exception, Вы писали:
UE>> Смущает только один момент. Как я понимаю, нельзя просто так собрать бинарники, чтобы они везде работали. Как же быть?
AB> * Распространять в исходниках (самый правильный вариант).
А есть какой-нибудь пример, когда шаровара, сделанная одним-двумя людьми, распространяется в исходниках, и кто-то за это платит?
Здравствуйте, Sharowarsheg, Вы писали:
S>Здравствуйте, Anton Batenev, Вы писали:
AB>>Здравствуйте, Unhandled_Exception, Вы писали:
UE>>> Смущает только один момент. Как я понимаю, нельзя просто так собрать бинарники, чтобы они везде работали. Как же быть?
AB>> * Распространять в исходниках (самый правильный вариант).
S>А есть какой-нибудь пример, когда шаровара, сделанная одним-двумя людьми, распространяется в исходниках, и кто-то за это платит?
Тут вот чувак говорит, что лимон баксов в год в одно рыло делает
Здравствуйте, Евгений Акиньшин, Вы писали:
S>>А есть какой-нибудь пример, когда шаровара, сделанная одним-двумя людьми, распространяется в исходниках, и кто-то за это платит?
ЕА>Тут вот чувак говорит, что лимон баксов в год в одно рыло делает
ЕА>https://www.indiehackers.com/podcast/016-mike-perham-of-sidekiq
О, прикольно. Это B2B, насколько я понимаю, но тем не менее.
Я только читаю тут его лицензии, и что-то в них нигде не написано, что он продаёт это вместе с исходниками. Поскольку я в вёбе (или что вообще это у него?), ни уха ни рыла, может кто-нибудь найдёт что-нибудь определённое?
В лицензионном соглашении написано, что бесплатная версия под LGPL, а про платные написано стандартное "запрещается декомпиляция, модификация, и всё такое".
Просто собирай статически на самом старом ядре, которое собираешься поддерживать и всё прекрасно будет работать. Обратная совместимость у линукса идеальная.
Здравствуйте, Sharowarsheg, Вы писали:
S>Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>>Тут вот чувак говорит, что лимон баксов в год в одно рыло делает
ЕА>>https://www.indiehackers.com/podcast/016-mike-perham-of-sidekiq
S>Я только читаю тут его лицензии, и что-то в них нигде не написано, что он продаёт это вместе с исходниками. Поскольку я в вёбе (или что вообще это у него?), ни уха ни рыла, может кто-нибудь найдёт что-нибудь определённое?
S>В лицензионном соглашении написано, что бесплатная версия под LGPL, а про платные написано стандартное "запрещается декомпиляция, модификация, и всё такое".
Не разбирался, чего там у него.
Другой пример, который я знаю хорошо — компоненты под .net и delphi. Большую часть можно купить с исходниками.
Много лет занимался .net компонентами, никогда из-за этого проблем не было.
