Распространение либ для C++

Шансы есть, если готов поддерживать наборы пакетов под зоопарки дистров (или явно ограничится двумя-тремя выбранными)

Qt например так распространяет, и не только закрытые

Но вообще дистронезависимые бинарники требуют более вдумчивого подхода, чем сборка под конкретные целевые дистры

У меня там предполагается не такой большой код. Зависимостей мало. Может быть, будет spdlog. Будет точно mpi. Может быть, boost. И собственно, все. Или пока еще чего-то не разглядел. Да, еще сериализаторы могут быть.

А есть универсальные практики? Или тут кроме как линковать старый libc или носить стандартную плюсовую либу с собой никак?

А есть универсальные практики? Или тут кроме как линковать старый libc

Это как бы основная практика, надо определить, насколько старая система нужна для сборки и сбалансировать широту охвата целевых дистрибутивов с возникающим гемором

или носить стандартную плюсовую либу с собой

Такой вариант годится только для приложений, но не для библиотек

Так же надо учитывать, какие зависимости помимо libc можно безопасно цеплять из системы (да, такое бывает, особенно часто с сишными библиотеками)

зоопарки дистров

Для проприетарщины? RHEL+Ubuntu и хватит

А есть универсальные практики?

https://www.akkadia.org/drepper/dsohowto.pdf

+версии

+архитектуры

• версии - да

Собираешь под Ubuntu LTS и CentOS да и собственно все?

есть шансы

Да.

собирал как-то свой софт на Qt на виртуалке с Centos 6 с помощью вот этого чуда https://www.softwarecollections.org/en/scls/rhscl/devtoolset-7/

получалось gcc седьмой версии (потому что нужен был c++11) + glibc 2.12

мог промахнуться в некоторых цифрах… суть была в том чтобы на debian stable тех лет запустилось и не собирать самому ни gcc, ничего

муторно было, но не так муторно как пересобирать gcc или glibc (последнее пытался - не получилось)

Поубивал бы гондонов, не выкладывающих исходный текст!

Пусть у тебя анально огороженная лицензия, но выложить исходники ты обязан! Хотя бы для того, чтобы пользователь мог твои косяки исправить, чтобы оно работало…

Пусть у тебя анально огороженная лицензия, но выложить исходники ты обязан!

Лицензия может защитить только от честных людей и (отчасти) от выкладывания на популярных площадках (см. историю с кодом Оперы).

Хотя бы для того, чтобы пользователь мог твои косяки исправить, чтобы оно работало…

По еуле пользователь не имеет права ничего там изучать и тем более исправлять, так что норм)

В науке не опенсорц не нафиг не сдался. Открою секрет, не в науке в числодробилках и бигдате его тоже очень не любят. Настолько, что стараются не использовать если хотя бы половина возможностей продукта есть у опенсорсного аналога, вторую половину сами навелосипедят. Исключение когда велосипедить половину надо годик другой, иначе слишком жесткий вендор лок и шаг вправо, шаг влево, прыжок на месте расстрел. А задачи с уклоном в науку (как в частный случай любой новой и не типичной задачи) требуют именно шагов влево, вправо, подпрыгивания и закапывания.

++ много.

Благодарю!

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

Я сталкивался с тем, что помимо отсутствующей экспертизы, потенциальных клиентов отпугивала от собственной разработки сама сложность и специфичность проблемы. Часто бывают ситуации, когда имеется исходный код, но автора уже нет, и никто разобраться не может/не хочет (потому что большей частью это УГ, а не код, но тем не менее он работает).

Иными словами, в принципе есть возможность распространять даже исходный код и тем не менее получать на этом деньги. Пока расходы клиентов (и финансовые, и временные) на собственную разработку будут выше чем платить тебе.

Правильно. Скажем так, если люди приличные а код отчуждаем (то есть можно скачать, прочитать доки и использовать), то если лицензия требует они с автором свяжутся и заплатят.

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

Кроме того квалифицированных исполнителей всегда остро не хватает, и проще нанять автора допилить/проинтегрировать его код куда то чем отвлекать на это свои ресурсы.

Поэтому у пользователя возникают вопросы/проблемы и он приходит к автору.

Я первый раз узнал о такой форме заработка когда знакомился с zeromq. Ее автор зарабатывал на консультациях, хотя сама библиотека полностью открытая и бесплатная.

Кроме того квалифицированных исполнителей всегда остро не хватает, и проще нанять автора допилить/проинтегрировать его код куда то чем отвлекать на это свои ресурсы.

Точно так

У меня уже был опыт опенсорса в интересующей меня области (нет, не на C++). Так не работает, по крайней мере, у меня не получилось, хотя количество скачиваний там просто фантастическое по моим меркам (роботы трудятся, скачивая все это?). Причем я и документацию на мой взгляд хорошую создал. Только когда нет продукта, то нет особого смысла развивать. Кто остается в выигрыше, когда код открыт? Ни потенциальные клиенты, ни сам владелец кода.

А если дело пойдет, то почему сразу ограничиваться одним человеком? Тут возможны и кооперации с существующими компаниями или даже создание собственной фирмы. Главное, чтобы заказы были.

C++ в этом смысле весьма интересен. К нему хорошая адаптация в этой области. Много известных мне существующих аналогов создано именно на C++, но я не знаю ни одного широкоиспользуемого опенсорсного для сложных задач.

А что за область у вас, если не секрет?

Кто остается в выигрыше, когда код открыт?

Что-то ты рассуждаешь как проприетасты! Ты хочешь и рыбку съесть, и кой-куда не сесть!

Зачем жить в мире сволочного капитализма? Тебе за код заплатили зарплату? Заплатили! Ну так выложи код на гитхаб, пусть люди пользуются.

А так ты чем-то сволочного мигалкова напоминаешь, который хочет, ничего не делая, деньги получать!

Хочешь денег? Работай! Не хочешь работать? Тогда и о деньгах не мечтай. Все просто.

Да не хотелось бы особо углубляться в это на публичном ресурсе. Не суть важно. Меня больше интересует сам метод, а имеет ли смысл в 2020 года распространять либу в виде объектных файлов и хедеров, хотя в некоторых случаях, возможно, что придется показывать исходники, но от этого не уйти там.

Успокойся, это мой и только мой код, хобби в свободное время.

Думаю, что да, смысл есть. Тут год роли не играет никакой.

Я тоже задумывался о подобном, но у меня сложнее ситуация - распространять можно только в исходном виде. Так вот я пришел к выводу, что в узкой области можно распространять даже в виде исходных кодов. Банально, но код может быть получен с помощью кодогенерации - там без обфускации-то трудно разобраться порой. А если это специфичная тема, то наличие исходного кода особо не помогает.

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

Ведь даже STL гораздо приятнее по Страуструпу изучать, чем по исходникам в том же gcc :)

Я свои либы (которые либы) распространяю свободно под апач2 (за исключением тех модулей которые юзают анально огороженный вирусный GPL2). За числом скачиваний не слежу, хотя выпустил пару статей в открытой печати, не считая постоянных упоминаний в своих работах и работах коллег которые их юзают.

Сейчас вот некая коллизия - сделали для заказчика новый метод расчет одной важной штуки, я бы его включил в соотв. либу и выложил в открытый доступ, но заказчик мнется и пока согласен только на публикацию статию с описанием алгоритма.

Но нам наверное чуть проще - нас привлекают что то посчитать, отчуждаемый код мы делаем крайне редко (это отдельная работа которую мы плохо умеем), обычно мы сами являемся интерфейсом к своим кодам (постоянно требуется какая то доработка под конкретные постановки) и тут уж заказчикам некуда деваться…

То есть, вы не совсем владельцы своего кода. Как оговорите в договорах, так и будет. Это вообще отдельная сложная тема. Меня предупреждали, что в подобном вашему случае даже публикацию статьи нужно оговаривать с теми, для кого выполнял. За этим нужно следить, конечно, и все время помнить о деле Сысоева :)

Э… библиотеке которой я занимаюсь в свободное от работы время я вполне владелец. Если я хочу туда включить что то сделанное на чьи то деньги - да, конечно надо согласовывать.

Ну а так то, там где я работаю, все статьи надо согласовывать… хорошо что на комментарии на ЛОР жто пока не распространяется

обычно мы сами являемся интерфейсом к своим кодам (постоянно требуется какая то доработка под конкретные постановки) и тут уж заказчикам некуда деваться

Вот я именно про этот самый случай.

Зависимостей мало.

Зато какие …

Может быть, будет spdlog. Будет точно mpi. Может быть, boost.

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

Зависимость от mpi - норм. Отчасти в этом и смысл :) Остальное не так важно. Например, в однопоточном коде я не увидел большого преимущества от использования local_shared_ptr вместо std::shared_ptr. Так что, буст постольку-поскольку.

А для триала можно отдавать собранные готовые с актуальными версиями open-mpi, mpich или ms-mpi.

Зависимость от mpi - норм.

С чего бы это? Разных вариантов mpi over 9000. Если ты слинковался с одной версией, то с другой у тебя не заработает.

Поубивал бы гондонов, не выкладывающих исходный текст!

С этим надо к психиатру, а не к ЛОРу.

но выложить исходники ты обязан

Это с какой стати? Потому что ты так сказал?

Хотя бы для того, чтобы пользователь мог твои косяки исправить, чтобы оно работало…

Хозяин кода решает, кто и что будет исправлять.

Предлагаю брать пример с gtkmm

В науке не опенсорц не нафиг не сдался.

Ну это смотря в какой науке. В квантовой химии, например, проприетарные проекты как были мейнстримом, так и остались :)

С чего бы это? Разных вариантов mpi over 9000. Если ты слинковался с одной версией, то с другой у тебя не заработает.

Готовой сборкой с актуальной версией, скажем, ms-mpi, можно заинтересовать людей. А если дело когда-нибудь дойдет и до чего-то серьезного, то можно собрать под хардварный mpi отдельно, под ту же Ангару. Пока план такой.

А что мешает сделать свою обертку для mpi и поставлять вместе с бинарем каких то уникальных алгоритмов исходник обертки? Потому что сборка на кластере это всегда мутотень, ещё не хватало каких то доп. ограничений…

Это все пока неопределено

Кстати, а есть ли MPI, где для wait (или аналога) можно было бы задать таймаут? Сидеть тупо проверять постоянно test не лучшее решение

В нормальной науке все вокруг СПО вертится, это только анально огороженная наука закрыта. А химия обычно финансируется всякими корпорациями, вот и получается эдакая копрофилия…

Создаешь демо-приложения под основные платформы («основные» - это те, которые ты считаешь основным). Собираешь либы под эти платформы, чтобы твое демо собиралось без особых проблем. Выкладываешь. Ждешь жалоб. По возможности и, конечно же, по прибыльности отвечаешь на эти жалобы.

Может быть, вообще, нафиг никому не нужно будет

Капиталист, зачем вкладывать больше, чем ожидаешь получить?

Собирать под винду, гонять в вайне. У винды всяко лучше поддерживаются динозавры.

Какой нафиг капиталист? Так, любитель-дилетант

Капиталист, любитель и дилетант - это 3 ортогональных понятия, можно сочетать, как захочется.

Поэтому выкладывай что есть как есть, вдруг поймаешь золотую рыбку.

Любая удача - это случайность. «Систематизировать» случайность будешь, рассказывая байки своим внукам.

С mpi, в вайне. Отличный план!:-)