Здравствуйте, Erop, Вы писали:
E>Исключенй два, и второе (ОО) неудачное. И оба сделаны на деньги спонсоров с целью завалить майкрософт... E>При этом я не знаю точно финансировал кто-то вроде IBM gcc или нет.
Опенсорс не значит отсутствия финансирования. Он лишь означает распределённую разработку, доступную каждому. То есть, к примеру, несколько компаний нанимают программистов и за более короткое время получают продукт с более широким охватом функциональности и возможностей, которые потом каждый и пользует. И ничего страшного в том, что это становится ещё и достоянием общественности, поскольку пользователи ещё и обучаются. Опенсорс это выгода, первым делом. И затраты, конечно же. А бесплатность для конечного пользователя и возможность модифицировать — детали.
Здравствуйте, Turtle.BAZON.Group, Вы писали:
TBG>Опенсорс не значит отсутствия финансирования. Он лишь означает распределённую разработку, доступную каждому. То есть, к примеру, несколько компаний нанимают программистов и за более короткое время получают продукт с более широким охватом функциональности и возможностей, которые потом каждый и пользует. И ничего страшного в том, что это становится ещё и достоянием общественности, поскольку пользователи ещё и обучаются. Опенсорс это выгода, первым делом. И затраты, конечно же. А бесплатность для конечного пользователя и возможность модифицировать — детали.
1) сказки это всё, про более широкий охват.
Но разговор вроде про финансы был, а не про открытость кода...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, vdimas, Вы писали:
V>Для рынка заказных библиотек продать не проблема, но возни много, ибо под конкретного клиента надо среду компиляции воссоздать, забилдить и оттестировать. А воссоздать среду, как уже говорил, это не просто некий линух из дистрибутива, это желательно со всеми изменениями и дополнениями, которые нагородил себе клиент. Геммор, короче. Почему так?
Есть клиент, он говорит, мне нужна либа и вот тебе платформы под которые она должна работать, производитель берёт и ставит себе эти платформы, ниже ты сам себе противоречишь, если платформа меняется раз в 5-10 лет то и на совместимость надо соответственно, раз в 5-10 лет , всё остальное время пиши себе фиксы и добавляй функционал. Вообще подготовка тестового окружения акция одноразовая, клиент стремиться свести зоопарк платформ к минимуму, мало того он заинтересован помочь организовать вам адекватное тестовое окружение, тут разумно иметь готовый образ системы, который обновляется синхронно с клиентом. Вообще разнообразие никсов, это одно из их преимуществ собственно клиент выбирая эту систему явно ими пользуется ну и отгребает недостатки тоже.
V>Просто все эти зависимости в RPM — одна большая фикция. Несколько примеров: V>1. указана зависимость libsome>=1.2.3, самая нубская и самая частовстречающаяся зависимость, грабля на ровном месте. Где гарантия, что со следующими версиями именно твой софт будет работать неплохо? Нету гарантии, что и наблюдается во время постоянных обновлений зависимых продуктов после обновления библиотеки.
Ставь жёсткую зависимоть libsome=1.2.3, кто тебе мешает? Я писал об этом выше, можно вообще свой репозиторий сделать, и держать там все зависимости вплоть до libc. V>2. сами эти бесконечные и детальные списки зависимостей от версий возможны только при наличии большого коммьюнити. Неужели ты не понимаешь, что суммарная общая трудоемкость тестирования пакетов этим коммьюнити может на 2-3 порядка превышать трудоемкость собственно разработки продукта?
Почему? Ты не можешь выставить или протестировать зависимости самостоятельно? Сколько у твоей либы зависимостей? Чаще всего это число меньше 5, и точно меньше 10. В самом худшем случае за год произодёт смена стабильной версии у всех зависимотсей, но в стабильные дистрибутивы они не попадут, туда попадают, обновления безопасности, а такие обновления ничего не ломают, ну если ты конечно не юзал дырку в безопасности. V>3. но даже бардак внутри прямых зависимостей ничто, по сравнению с наведенными эффектами: какой-то пакет проставил свежую свою версию чего-то там, перекинул симв. линк в другое место, и твой софт может умереть, ибо он аккуратно обходил баг предыдущей версии, а без бага... не работает. Да-да, в коммерческом исполнении это был бы старый добрый до-winXP DLL hell, и обязательный саппорт старых багов ввиду требований совместимости... это опенсорсу хорошо — он на все эти "мелочи" ложит с прибором, как ломает не спеша, так не спеша и чинит.
Погоди симлинк идет на libsome.a, а реальный файл libsome.1.2.3.a и имеено с ней линкуется приложение. У меня на машине нормально сосуществовало 2 версии libx264, более старшей и оптимизированной под проц версией пользовался mplayer/mencoder, тоже оптимизированные, а xine и прочие пользовали версию из дистрибутива и ничего не ломалось. ld всё это нормально разруливает, пакету просто надо зарегестрировать либу.
V>Как ты представляешь себе разруливание 2-го пункта? Опен сорс, который ни за что не в ответе, может позволить себе выпускать бесконечные версии и допиливать их по мере фидбэка от коммьюнити, а у коммерчесских заказчиков и коммьюнити-то не будет, т.к. за деньги люди не стремятся улучшить твой продукт, они будут на компанию-разработчика материться и спрашивать — за что заплачены деньги. Поверь, добровольно искать причины несовместимости и репортить готовые решения, как это делается в opensource-коммьюнити, никто не будет. (пусть тебя не смущает абсолютность заявы, даже если и найдутся пару чел, "по привычке" помогающих бесплатно любимым юниксам, то они погоду не сделают).
Это всё зависит от ответственности которую берёт на себя производитель. Для массового софта комьюнити создать не сложно и выгодно, и ответственность там ниже, т.к. потеря одного клиента неприятна, но не критична. Для заказного степень отвественности выше, поэтому все зависимости жёские или вообще лежат в своём репозитории, но тогда обновления безопасности будут недоступны, так что тут лучше просто взаимодействовать с коммандой безопасности соответствующего дистрибутива, и накатывать эти изменения раньше клиентов. Может быть такое, что безопасность пофигу, тогда и версии можно не обновлять.
V>В общем, никакая адекватная массовая коммерческая модель тут не выживает. Выживают лишь конкретно-заточенные решения. И когда заказчик апгрейдится (по софту или железу, рано или поздно), то он периодически обращается к разным поставщикам для устранения вновь приобретенных проблем. Поэтому и общеизвестно, что по итогам эксплуатации юнихи и линух в т.ч. очень дорогие, потому и не ставят на рабочие системы никаких обновлений обычно... и речь не о "самых свежих версиях ядра", коммерческие системы по 5-10 лет работают без апгрейда, выжимают из них все соки, ибо опытные начальники IT-отделов прекрасно знают цену этих игр в апгрейды на юнихах.
Если это окружение настолько стабильно откуда берутся несовместимости?
V>----------- V>Продолжая про классический dll hell. Как указывать зависимости от самого себя, т.е. как себя декларировать для окружающих? На момент выпуска неизвестно, в каких будущих версиях будут ломающие изменения, тем не менее разработчик хочет оставить за собой право делать текущие обновления (меняя версии, разумеется). В виндах, начиная с 2001-го эту проблему красиво решили с помощью манифеста, там можно ориентироваться на public token key, т.е. указывать зависимость по смыслу так: libsome>=1.2.3, p/t/key="abcd0123". И тогда, в случае ломающих изменений, надо просто сменить p.t.key в следующей версии, он служит идентификатором этой "группы совместимости", и загрузчик по манифесту определяет, какую версию DLL лучше всего загружать.
Задаёшь жесткую зависимость от пакета .
V>Короче, цель этих манифестов была — добавить еще один признак к номеру версии, отвечающий за совместимость (еще зависимости с конкретным бинарником сопоставлять, а не со всем абстрактным "пакетом", ибо это проще на порядки). Мне, как разработчику, прописывать зависимости в виндах — одно удовольствие, и я достоверно знаю, что однажды прописанную зависимость не надо будет постоянно корректировать. На фоне этого, нынешние системы зависимости "пакетов" в линухах — это прошлый век и фундаментально непреодолимый головняк для отдельно взятых разработчиков (помним о кол-ве необходимого тестирования).
Может стоит получше ознакомится с возможностями пакетных менеджеров? В Дебиане они почему то снижают затраты на тестирование, можно использовать подобную схему для тестирования новых версий зависимостей.
Вообще это всё можно решить так же как и под виндой, никто ведь за рога то не держит, в итоге есть один пакет, который зависит только от libc, а то и от него не зависит.
Ты тут описал проблемы не специфичные для библиотек, для библиотек автоматизация тестирования намного проще, собственно за те же деньги можно охватить больше.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
M>>Это не художественное цитирование. TurtleBazon утверждает, что в опенсорсе поют цветы и поют птички, что там опакечиванием (видимо всего и вся) занимаются специальные люди и проблем с опакечиванием чего-либо вообще в опенсорсе нет (вот это — художественное цитирование).
TBG>Не нужно перевирать мои слова. Я утверждаю, что опакечиванием занимаются нужных вещей, которые нужны дистрибутиву. А не всего и вся. Всего и вся никто заниматься не будет и дистрибутива на все случаи жизни тоже не будет.
Кто выбирает то, что нужно для дистрибутива? Формально. Не надо говорить мне про гипотетическое коммьюнити. Я вон выше привел пример. В обной версии есть библиотека к sphinx'у, и только в следующей версии — сам sphinx. Это, видимо, результат работы того самого коммьюнити.
M>>Не будут. Потому что это тоже люди и их ресурсы тоже ограничены
TBG>Это не мифические мейнтейнеры, которые за нулевой промежуток времени опакечивают бесконечное количество пакетов. Но если пакет востребован обществом — на него ресурсы найдутся.
Даже если он востребован, ресурсы не обязательно найдутся. Потому что никто никому ниего не должен. И метрик, определяющих нужность пакета, нет никаких.
V>>1. указана зависимость libsome>=1.2.3, самая нубская и самая частовстречающаяся зависимость, грабля на ровном месте. Где гарантия, что со следующими версиями именно твой софт будет работать неплохо? Нету гарантии, что и наблюдается во время постоянных обновлений зависимых продуктов после обновления библиотеки. DC>Ставь жёсткую зависимоть libsome=1.2.3, кто тебе мешает? Я писал об этом выше, можно вообще свой репозиторий сделать, и держать там все зависимости вплоть до libc.
Пытался я тут сегодня поставить php-fpm на убунту 8.10. Тоже с репозитория (dotdeb).
При попытке установить мне понавылезало что-то типа:
Unresolved dependencies
libapache_mod_php depends on php_common=5.2.4, php_common_5.2.5 will be installed
.
. еще 4 похожие фигни, не только с php связаные
.
run apt-get -f install to correct
apt-get -f install предложил снести всю систему нафиг (88 пакетов,включая апач и какие-то убунтовские файлы)
Здравствуйте, dr.Chaos, Вы писали:
DC>Есть клиент, он говорит, мне нужна либа и вот тебе платформы под которые она должна работать, производитель берёт и ставит себе эти платформы, ниже ты сам себе противоречишь, если платформа меняется раз в 5-10 лет то и на совместимость надо соответственно, раз в 5-10 лет
Ну ты весело рассуждаешь, особенно про противоречия. Один клиент всего, что-ли?
V>>Просто все эти зависимости в RPM — одна большая фикция. Несколько примеров: V>>1. указана зависимость libsome>=1.2.3, самая нубская и самая частовстречающаяся зависимость, грабля на ровном месте. Где гарантия, что со следующими версиями именно твой софт будет работать неплохо? Нету гарантии, что и наблюдается во время постоянных обновлений зависимых продуктов после обновления библиотеки. DC>Ставь жёсткую зависимоть libsome=1.2.3, кто тебе мешает?
Дык, не всегда эта зависимость непосредственная, мы ее можем получить коссвенно.
DC>Я писал об этом выше, можно вообще свой репозиторий сделать, и держать там все зависимости вплоть до libc.
Т.е. пол-линукса своего ставить.
V>>2. сами эти бесконечные и детальные списки зависимостей от версий возможны только при наличии большого коммьюнити. Неужели ты не понимаешь, что суммарная общая трудоемкость тестирования пакетов этим коммьюнити может на 2-3 порядка превышать трудоемкость собственно разработки продукта? DC>Почему? Ты не можешь выставить или протестировать зависимости самостоятельно? Сколько у твоей либы зависимостей? Чаще всего это число меньше 5, и точно меньше 10.
Ты давно последний раз ldd вызывал для более-менее сложных программ и всех ее динамических библиотек из поставки? А теперь прикинь, что мы оттестили прогру в некоем окружении, и выставили, как ты посоветовал, точные зависимости =, а не >=/<=. В итоге мы получили установочный пакет "одного клиента".
DC>Погоди симлинк идет на libsome.a, а реальный файл libsome.1.2.3.a и имеено с ней линкуется приложение. У меня на машине нормально сосуществовало 2 версии libx264, более старшей и оптимизированной под проц версией пользовался mplayer/mencoder, тоже оптимизированные, а xine и прочие пользовали версию из дистрибутива и ничего не ломалось. ld всё это нормально разруливает, пакету просто надо зарегестрировать либу.
Коммерческие либы редко распространяют как статические. А вот динамические либы или исполняемые файлы или служебные — простор для dll hell.
DC>Это всё зависит от ответственности которую берёт на себя производитель. Для массового софта комьюнити создать не сложно и выгодно, и ответственность там ниже, т.к. потеря одного клиента неприятна, но не критична. Для заказного степень отвественности выше, поэтому все зависимости жёские или вообще лежат в своём репозитории, но тогда обновления безопасности будут недоступны, так что тут лучше просто взаимодействовать с коммандой безопасности соответствующего дистрибутива, и накатывать эти изменения раньше клиентов. Может быть такое, что безопасность пофигу, тогда и версии можно не обновлять.
Вот, примерно так. Ну еще пару шрихов и станет окончательно понятно, почему никто не торопится на линухи. Массовый софт там невозможен без той или иной разновидности комьюнити и опенсорса, узкоиндивидуально — это не так много ниш, а все остальное пространство рыночных ниш, м/у "очень массовым" и "очень индивидуальным" представляются малоперспективными с комерческой точки зрения, ибо все эти хлопоты, что ты мне описываешь, окупаются с трудом.
V>>В общем, никакая адекватная массовая коммерческая модель тут не выживает. Выживают лишь конкретно-заточенные решения. И когда заказчик апгрейдится (по софту или железу, рано или поздно), то он периодически обращается к разным поставщикам для устранения вновь приобретенных проблем. Поэтому и общеизвестно, что по итогам эксплуатации юнихи и линух в т.ч. очень дорогие, потому и не ставят на рабочие системы никаких обновлений обычно... и речь не о "самых свежих версиях ядра", коммерческие системы по 5-10 лет работают без апгрейда, выжимают из них все соки, ибо опытные начальники IT-отделов прекрасно знают цену этих игр в апгрейды на юнихах.
DC>Если это окружение настолько стабильно откуда берутся несовместимости?
Еще раз большими буквами — у разных клиентов м/у собой. Каждый — уникален, а их сотни. Это у вас "большая" спец.система и пальцев одной руки хватит клиентов посчитать.
V>>----------- V>>Продолжая про классический dll hell. Как указывать зависимости от самого себя, т.е. как себя декларировать для окружающих? На момент выпуска неизвестно, в каких будущих версиях будут ломающие изменения, тем не менее разработчик хочет оставить за собой право делать текущие обновления (меняя версии, разумеется). В виндах, начиная с 2001-го эту проблему красиво решили с помощью манифеста, там можно ориентироваться на public token key, т.е. указывать зависимость по смыслу так: libsome>=1.2.3, p/t/key="abcd0123". И тогда, в случае ломающих изменений, надо просто сменить p.t.key в следующей версии, он служит идентификатором этой "группы совместимости", и загрузчик по манифесту определяет, какую версию DLL лучше всего загружать.
DC>Задаёшь жесткую зависимость от пакета .
Я же думал понятно и так, что получится (повторюсь) "пакет одного клиента". Каково комбинаторное сочетание хотя бы из трех десятков зависимостей, в предположении, что по каждой из них 2-5 активноиспользуемых на рынке версий? (за минусом их внутренних зависимостей)
V>>Короче, цель этих манифестов была — добавить еще один признак к номеру версии, отвечающий за совместимость (еще зависимости с конкретным бинарником сопоставлять, а не со всем абстрактным "пакетом", ибо это проще на порядки). Мне, как разработчику, прописывать зависимости в виндах — одно удовольствие, и я достоверно знаю, что однажды прописанную зависимость не надо будет постоянно корректировать. На фоне этого, нынешние системы зависимости "пакетов" в линухах — это прошлый век и фундаментально непреодолимый головняк для отдельно взятых разработчиков (помним о кол-ве необходимого тестирования).
DC>Может стоит получше ознакомится с возможностями пакетных менеджеров? В Дебиане они почему то снижают затраты на тестирование, можно использовать подобную схему для тестирования новых версий зависимостей.
Дебиан подробно не изучал, но не думаю, что возможности сильно отличаются от RPM. Тем более, что под RPM заказчиков подавляющее большинство.
DC>Вообще это всё можно решить так же как и под виндой, никто ведь за рога то не держит, в итоге есть один пакет, который зависит только от libc, а то и от него не зависит.
Да, по максимуму и так линкуется статически, но какой-нить MySQL и прочее ты же статически себе не залинкуешь. Опять же, это не очень хорошая практика, какие-нить библиотеки SSL и прочее из разряда безопасности к себе статически подлинковывать, по понятным причинам — здесь просто обязательное требование работать с самыми последними версиями. А те в свою очередь имеют зависимости... В общем, читай сначала.
Опять же, если предоставляешь в своем АПИ функциоанльность std:: С++ исключений и поставляешь как so, то, чтобы не было проблем с несовместимостью RTTI и неудачной ловлей этих исключений на клиентской стороне, вы должны ссылаться на одну и ту же динамическую C++ std либу.
А вообще, чего тут без толку рассуждать? Ты просто попробуй поставить более-менее сложный RPM от "чужого" дистрибутива. И версии либ у тебя совпадут, и версия ядра, а поставишь — и будет все падать. А падать она может из-за любой причина из миллиона, и все их тут неспеша пережевывать уже неинтересно, важем сам факт. Хорошо, если только поставленная программа будет падать, а то ведь система в целом может урониться до неподъемного состояния, и откатывать назад нечем будет (разве только с бэкапа... представляю в readme коммерческого продукта: сделайте полный бэкап системы перед установкой нашей приблуды ).
В общем, какие бы сценарии ты не описывал, они все применимы с точностью лишь до одного конкретного клиента с его уникальным дистром (один федор одновременно популярных штук 6), когда же клиентов хотя бы десятки и сотни — это ппц.
Здравствуйте, Mamut, Вы писали:
M>apt-get -f install предложил снести всю систему нафиг (88 пакетов,включая апач и какие-то убунтовские файлы)
M>Какие есть предложения?
Ну так тебе стабильность уже работающего нужна или новая софтина? Выбирай . Можешь скачать dev-пакеты и собрать сам под 8.10. И вообще все претензии к dotdeb, они же пакеты собирали.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, Mamut, Вы писали:
M>Кто выбирает то, что нужно для дистрибутива? Формально. Не надо говорить мне про гипотетическое коммьюнити. Я вон выше привел пример. В обной версии есть библиотека к sphinx'у, и только в следующей версии — сам sphinx. Это, видимо, результат работы того самого коммьюнити.
Общество пользователей и выбирает. Если нужно — возникает. А конечные пользователи уже выбирают дистрибутив. А про sphinx — значит, так нужен, раз такая ситуация с ним. И эта ситуация не показатель вообще. Кстати, неудачный он.
Здравствуйте, Mamut, Вы писали:
M>Даже если он востребован, ресурсы не обязательно найдутся. Потому что никто никому ниего не должен. И метрик, определяющих нужность пакета, нет никаких.
Если востребован, то по теории вероятности найдётся кто-нибудь, кто предложит собрать. А дальше собрать не такая уж и большая проблема.
Здравствуйте, Константин Б., Вы писали:
КБ>Пользователь за такой юзер-экспириенс, как сборка софта из сорцов ни то что не заплатит, а скорей еще сам денег потребует.
Если нужно, то несложно набрать ./configure && make && make install
Программы, которые написаны с ориентацией на стандарты, как правило, таким образом соберутся без пролем.
Здравствуйте, Mamut, Вы писали:
M>Не знаю, что такое zabiss, и зачем он нужен Я вот недавно устанавливал sphinx search. Из исходников. Не нарвался на installation issues по чистой случайности. ./configure не помог бы Правда, мне пришлось править исходник в одном месте уже потом, на этапе компиляции...
Выкинь каку под названием sphinx search. Это поиск для бедных.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, dr.Chaos, Вы писали:
DC>>Есть клиент, он говорит, мне нужна либа и вот тебе платформы под которые она должна работать, производитель берёт и ставит себе эти платформы, ниже ты сам себе противоречишь, если платформа меняется раз в 5-10 лет то и на совместимость надо соответственно, раз в 5-10 лет
V>Ну ты весело рассуждаешь, особенно про противоречия. Один клиент всего, что-ли?
А остальные не дают?
Я не думаю что найдётся более 10-ка очень разных конфигураций, т.к. ентерпрайз сидит на RHEL и SLES. Давай таки оценим вот за последние 10 лет сколько вышло стабильных релизов RHEL, SLES, Debian и Ubuntu. Причём 1-е 2 будут встерачться значительно чаще. В рамках стабильного релиза мы имеем только обновления безопасности, т.е. майнтейнер закрывает дыры без инменения функционал и интерфейсов. Ну всё ещё сотни или уже десятки?
V>Дык, не всегда эта зависимость непосредственная, мы ее можем получить коссвенно.
Можем, но на стабильном дистрибутиве это маловероятно.
V>Т.е. пол-линукса своего ставить.
Ну под виндой та же фигня, если зависимостей много, то тоже всё с собой таскается, опыт есть.
V>Ты давно последний раз ldd вызывал для более-менее сложных программ и всех ее динамических библиотек из поставки? А теперь прикинь, что мы оттестили прогру в некоем окружении, и выставили, как ты посоветовал, точные зависимости =, а не >=/<=. В итоге мы получили установочный пакет "одного клиента".
Нет для одной системы, почти такая же может стоять ещё у сотен. Особенно если брать интерпрайс.
DC>>Погоди симлинк идет на libsome.a, а реальный файл libsome.1.2.3.a и имеено с ней линкуется приложение. У меня на машине нормально сосуществовало 2 версии libx264, более старшей и оптимизированной под проц версией пользовался mplayer/mencoder, тоже оптимизированные, а xine и прочие пользовали версию из дистрибутива и ничего не ломалось. ld всё это нормально разруливает, пакету просто надо зарегестрировать либу.
V>Коммерческие либы редко распространяют как статические. А вот динамические либы или исполняемые файлы или служебные — простор для dll hell.
Это я по привычке .a написал, имелся ввиду .so . Те в примере была динамическая либа.
V>Вот, примерно так. Ну еще пару шрихов и станет окончательно понятно, почему никто не торопится на линухи. Массовый софт там невозможен без той или иной разновидности комьюнити и опенсорса, узкоиндивидуально — это не так много ниш, а все остальное пространство рыночных ниш, м/у "очень массовым" и "очень индивидуальным" представляются малоперспективными с комерческой точки зрения, ибо все эти хлопоты, что ты мне описываешь, окупаются с трудом.
Не ну если ты себя в чём то уже убедил, я тут бессилен . Вон тот же Оракл гарантирует стабильность своих продуктов только для стабильных дистров. Просто обсуждая сферический продукт в вакууме можно напридумывать много всего, а по факту клиент платит за то, чтоб работало, причём он готов платить за это даже свободным и открытым проектам. Что мешает зарабатывать на зоопарке? При выходе на рынок всё равно ты же знаешь его целевой сегмент, кто тебе мешает оценить разнообразие дистров в этой нише? Это вполне можно сделать по открытым источникам.
Я так и не понял что за затраты: на тестирование? на поддержку? Тестируем и поддерживаем только на стабильных версиях, да если софт критичен, то клиент ничего другого и не поставит. Поддержка на них тоже не так уж затратна.
DC>>Если это окружение настолько стабильно откуда берутся несовместимости?
V>Еще раз большими буквами — у разных клиентов м/у собой. Каждый — уникален, а их сотни. Это у вас "большая" спец.система и пальцев одной руки хватит клиентов посчитать.
Ну я тебе предложил мне найти сотни разных стабильных дистрибутивов, для одного сегмента рынка.
V>>>----------- V>>>Продолжая про классический dll hell. Как указывать зависимости от самого себя, т.е. как себя декларировать для окружающих? На момент выпуска неизвестно, в каких будущих версиях будут ломающие изменения, тем не менее разработчик хочет оставить за собой право делать текущие обновления (меняя версии, разумеется). В виндах, начиная с 2001-го эту проблему красиво решили с помощью манифеста, там можно ориентироваться на public token key, т.е. указывать зависимость по смыслу так: libsome>=1.2.3, p/t/key="abcd0123". И тогда, в случае ломающих изменений, надо просто сменить p.t.key в следующей версии, он служит идентификатором этой "группы совместимости", и загрузчик по манифесту определяет, какую версию DLL лучше всего загружать.
DC>>Задаёшь жесткую зависимость от пакета .
V>Я же думал понятно и так, что получится (повторюсь) "пакет одного клиента". Каково комбинаторное сочетание хотя бы из трех десятков зависимостей, в предположении, что по каждой из них 2-5 активноиспользуемых на рынке версий? (за минусом их внутренних зависимостей)
А вот теперь ограничь это всё теми версиями что лежат в стабильных дистрах, а то я тоже страшилки про обновления безопасности под виндой напевать могу.
V>Дебиан подробно не изучал, но не думаю, что возможности сильно отличаются от RPM. Тем более, что под RPM заказчиков подавляющее большинство.
Вот, ты тут опять всё сводишь к RHEL и SLES. Всё ещё комбинаторика в зависимостях? Или мейнтейнеры от этого оберегают? Deb помощьнее rpm-ов, но для данного случая разницы особой нет.
DC>>Вообще это всё можно решить так же как и под виндой, никто ведь за рога то не держит, в итоге есть один пакет, который зависит только от libc, а то и от него не зависит.
V>Да, по максимуму и так линкуется статически, но какой-нить MySQL и прочее ты же статически себе не залинкуешь. Опять же, это не очень хорошая практика, какие-нить библиотеки SSL и прочее из разряда безопасности к себе статически подлинковывать, по понятным причинам — здесь просто обязательное требование работать с самыми последними версиями. А те в свою очередь имеют зависимости... В общем, читай сначала. V>Опять же, если предоставляешь в своем АПИ функциоанльность std:: С++ исключений и поставляешь как so, то, чтобы не было проблем с несовместимостью RTTI и неудачной ловлей этих исключений на клиентской стороне, вы должны ссылаться на одну и ту же динамическую C++ std либу.
А под видной что легче рулить зоопарк из MySQL и SSL? Кто тебе пришлёт обновление связанное с безопасностью из старшей версии? Мейнтейнеры дают стабильное окружение и ещё накладывают патчи связанные с безопасностью, на винде это окружение твоя головная боль и головная боль клиента, т.к. он взял и обновил себе MySQL с формулировкой: "Я в интренетах прочитал, что он типа круче", а под стибильный дистр линукса это сделать сложнее.
V>А вообще, чего тут без толку рассуждать? Ты просто попробуй поставить более-менее сложный RPM от "чужого" дистрибутива. И версии либ у тебя совпадут, и версия ядра, а поставишь — и будет все падать. А падать она может из-за любой причина из миллиона, и все их тут неспеша пережевывать уже неинтересно, важем сам факт. Хорошо, если только поставленная программа будет падать, а то ведь система в целом может урониться до неподъемного состояния, и откатывать назад нечем будет (разве только с бэкапа... представляю в readme коммерческого продукта: сделайте полный бэкап системы перед установкой нашей приблуды ).
Не сложный, правда, но ставил, в зависимостях было либ 10 точно. Декодер в RMP-е был я его на Ubuntu поставил. Он безусловно недостаточно сложный, предупреждая ответ. Но скажи мне, нафига кому-то ставить сложный пакет из чужого дистра? Не для фана конечно прокатит, но бизнесс таким не промышляет.
V>В общем, какие бы сценарии ты не описывал, они все применимы с точностью лишь до одного конкретного клиента с его уникальным дистром (один федор одновременно популярных штук 6), когда же клиентов хотя бы десятки и сотни — это ппц.
Федора не стабильный дистр , для него никаких гарантий стабильности окружения. Посему весь софт для дистров не предоставляющих таких гарантий будет требовать много средств на самостоятельное их обеспечение. Но и ниша у таких дистрибутивов совершенно иная, там люби платят деньги не за стабильность.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, Mamut, Вы писали:
S>>Есть. Избавляйся нафиг от бинарных дистрибутивов.
M>И? source-based вдруг магичесим образом решат эту проблему?
Сдается мне, Sheridan поздно родился. Ему бы ОС ЕС погенерировать. На всю жизнь хватит. Мне вот не пришлось. Говорят, там и из исходников, и на ассемблере все, и каждой железке ручками параметры подбирать. Пусть меня поправят, если я наврал.
