Комментарии 105
А в России, по крайней мере, в зравоохранении активно любят Interbase-семейство. Это потому, что всё разрабатывается с Delphi (больше толком и не преподают ничего, соответственно, не умеют), а БД семейства Interbase в него включаются несколькими движениями пальцев.
Из БД собственно сейчас наиболее активно используют Yaffil, т.е. насилуют труп, который его разработчики закопали ещё в 2003.
Прекращение разработки Yaffil было связано с тем, что решили не распыляться, а поддерживать другой проект семейства — Firebird. Который и сейчас разрабатывается, недавно вышла версия 2.5. Это — в чистом виде Open Source.
Некоторые программы и так способны работать с Firebird (Yaffil используется «по традиции» или потому, что сервер ставили давно). А некоторые не работают, но разработчики намечают мигрировать на него.
Из БД собственно сейчас наиболее активно используют Yaffil, т.е. насилуют труп, который его разработчики закопали ещё в 2003.
Прекращение разработки Yaffil было связано с тем, что решили не распыляться, а поддерживать другой проект семейства — Firebird. Который и сейчас разрабатывается, недавно вышла версия 2.5. Это — в чистом виде Open Source.
Некоторые программы и так способны работать с Firebird (Yaffil используется «по традиции» или потому, что сервер ставили давно). А некоторые не работают, но разработчики намечают мигрировать на него.
Да в Украине тоже Interbase был (по крайней мере лет 5 назад) распространен в ПО для здравоохранения. Я во всяком случае имел дело с ПО к рентген установке. Хотя там это было из пушки по воробьям. Там вполне хватило бы какого-нибудь MS.Jet.
Хотя сейчас часто можно встретить ПО Delphi+Oracle, Delphi + MS SQL Express и не обязательно корпоративное.
Но сам тоже использую Firebird и не только из Delphi, а еще из PHP и опосредованно из Javascript. В основном, конечно, потому что знаком с ним вдоль и поперек еще из Delphi.
Хотя сейчас часто можно встретить ПО Delphi+Oracle, Delphi + MS SQL Express и не обязательно корпоративное.
Но сам тоже использую Firebird и не только из Delphi, а еще из PHP и опосредованно из Javascript. В основном, конечно, потому что знаком с ним вдоль и поперек еще из Delphi.
До 2006 года вся билинговая система городской телефонной сети (не Москва) висела на FoxPro и данные в из базы в базу пересылались по почте, где роботом парсились и синхронизились с главной базой… разумеется из-за всего этого и возникали ситуации «я платил за телефон, а мне пеня приходит». Как сейчас там обстоит ситуация не знаю.
Пиратский Interbase на пиратском Delphi с купленного в ларьке диска «Всё для программиста»?..
А вы думали, почему в середине-конце девяностых у нас было столько программистов, которых на западе с руками отрывали, в то время как большинство пакетов для программирования, в том числе вышепомянутый Дельфи, стоили баснословные деньги даже по тем временам?
А я-то думал, это всё из-за традиций хорошего, фундаментального образования в области точных наук в exUSSR.
Причем здесь традиции и возможность взять последнюю IDE в самой навороченной комплектации за $3 а не за $999? Традиции и знания хорошо, но если их негде применять акромя Бейсика компьютерном классе на ZX (реальная ситуация на середину 90х), то грош им цена.
И еще вопрос, дабы не отходить от кассы: какие мегасупер знания фундаментального толка в середине 90 начала 2000 мог получить обычный средне-старше классник совершенно обычной школы? А получить Delphi 5 С кучей дорогущих компонентов и учебником «дельфи для чайников» вполне можно было тогда.
зы: чтобы не было недопонимания, да, были отличные школы и И. где учили хорошо и это потом хорошо аукнулось ученикам, достаточно посмотреть где учились основатели известнейших российских фирм. но в целом по стране массовый «урожай» программистов дала именно доступность средств разработки, ведь это сейчас есть Vs express, eclipse И прочее, а тогда это все было за дееьги и немалые, так что вопрос «а не купить ли сыночку последнюю модную Ide За Цать штук баксов» всегда проигрывал Диску «Все о Delphi» за 50 рублей
И еще вопрос, дабы не отходить от кассы: какие мегасупер знания фундаментального толка в середине 90 начала 2000 мог получить обычный средне-старше классник совершенно обычной школы? А получить Delphi 5 С кучей дорогущих компонентов и учебником «дельфи для чайников» вполне можно было тогда.
зы: чтобы не было недопонимания, да, были отличные школы и И. где учили хорошо и это потом хорошо аукнулось ученикам, достаточно посмотреть где учились основатели известнейших российских фирм. но в целом по стране массовый «урожай» программистов дала именно доступность средств разработки, ведь это сейчас есть Vs express, eclipse И прочее, а тогда это все было за дееьги и немалые, так что вопрос «а не купить ли сыночку последнюю модную Ide За Цать штук баксов» всегда проигрывал Диску «Все о Delphi» за 50 рублей
Потому, что в середине-конце девяностых был доткомовский бум
Именно так. Во второй половине 90-ых я пришел к выводу, что поддерживать нужный уровень надежности программ, написанных на FoxPro, я не могу в принципе. Да и преимущества технологии клиент-сервер были очевидны. Интернета в те времена для простых смертных не было, литературы не было, о бесплатных решениях слыхом не слыхивали. Найти софт можно было только на пиратских дисках. Доступны были и Oracle, и Sybase, и DB/2, но документацию я нашел лишь на Interbase, что и определило выбор. Надо сказать, выбор был удачный. А лицензию мы вскоре купили.
Завтра иду восстанавливать базу данных, проработавшую 10 лет под управлением Interbase 4.2 и обслуживавшуюся один раз в 2-3 года. Судя по описанию проблемы, полетела файловая система. Судорожно вспоминаю, как работать с gbak… =)
Завтра иду восстанавливать базу данных, проработавшую 10 лет под управлением Interbase 4.2 и обслуживавшуюся один раз в 2-3 года. Судя по описанию проблемы, полетела файловая система. Судорожно вспоминаю, как работать с gbak… =)
Альтернатива то есть, только не все хотят переводить свои mission-critical приложения на open source. Обычно жалуются на надежность, потому как в плане отказоустойчивости, проприетарные СУБД пока впереди — сказывается объем инвестиций человеко-столетий в R&D. Один час простоя mission-critical системы крупного предприятия стоит уж очень много денег. Так что отказоустойчивость — это не то, на чем обычно хотят экономить (хотя всегда есть желающие поучиться на своих ошибках). С другой стороны, есть полно случаев когда проприетарная СУБД действительно не нужна.
Поэтому правильно было бы говорить не о «проприетарные СУБД vs open source СУБД», а о случаях когда лучше одно, а когда лучше другое. Нельзя приписывать одно лекарство на все случаи жизни — нужно подходить индивидуально.
Поэтому правильно было бы говорить не о «проприетарные СУБД vs open source СУБД», а о случаях когда лучше одно, а когда лучше другое. Нельзя приписывать одно лекарство на все случаи жизни — нужно подходить индивидуально.
Я согласен, что не в любом решении можно заменить проприетарную СУБД на открытую. Тут, действительно, нужен индивидуальный подход.
Что же касается mission-critical приложений, то EnterpriseDB, даёт гарантии и поддержку не хуже чем IBM/Oracle/MS. Это, опять же, не на всё, но при ценах в разы меньших, чем например у Oracle, есть хороший повод подумать. Особенно. когда нужна СУБД не на один сервер, а на сотню-другую. ;-)
Что же касается mission-critical приложений, то EnterpriseDB, даёт гарантии и поддержку не хуже чем IBM/Oracle/MS. Это, опять же, не на всё, но при ценах в разы меньших, чем например у Oracle, есть хороший повод подумать. Особенно. когда нужна СУБД не на один сервер, а на сотню-другую. ;-)
Если речь идет о РФ, то есть ли у EnterpriseDB партнеры, которые могут осуществлять поддержку прямо здесь? Или я должен буду себе специалиста из заграницы выписывать?
есть postgresmen.ru/ — там работают разработчики postgres и эта контора обеспечивает поддержку в РФ, думаю с enterprisedb они тоже знакомы
Нет, я то про них знаю, но я технический специалист. А предположим, что я CEO какого-нибудь «НЕФТЕТРАНСГАЗОСОС».
У меня есть mission-critical система «НЕФТЕТРАНСГАЗОБИЛЛ (тм)», которая может работать на Oracle или на Postgresql. За минуту простоя мы теряем 100к$.
И я не понимаю, с кем мне договор на поддержку подписывать? С EnterpriseDB или с Postgresmen? Тогда зачем мы здесь вообще об EnterpriseDB заговорили, раз они не могут поддержки mission-critical систем в РФ организовать.
У меня есть mission-critical система «НЕФТЕТРАНСГАЗОБИЛЛ (тм)», которая может работать на Oracle или на Postgresql. За минуту простоя мы теряем 100к$.
И я не понимаю, с кем мне договор на поддержку подписывать? С EnterpriseDB или с Postgresmen? Тогда зачем мы здесь вообще об EnterpriseDB заговорили, раз они не могут поддержки mission-critical систем в РФ организовать.
Может, конечно, они и знакомы, но все-таки EnterpriseDB и Постгресмен это две большие разницы. Первая оказывает услуги корпоративной поддержки мирового уровня для крупнейших компаний, а вторая выполняет локальные проекты.
Google говорит, что существует компания VDEL, которая является официальным партнёром EnterpriseDB и оказывает поддержку в РФ.
Не хочу никого обидеть, но вот смотрю на их сайт и как-то не возникает желания с ними договор на поддержку подписывать. А вот захожу, например, на сайт рдтеха (http://www.rdtex.ru), и сразу вижу чем они занимаются, и чего уже добились.
А машину вы себе исключительно по цвету выбираете? ;-)
Забавно, что вы упомянули сайт именно рдтеха, по слухам, поддержкой enterprisedb в России занимается, в числе прочих, и человек, который несколько лет проработал в рдтехе и ушел оттуда с должности архитектора СУБД.
Это я к тому, что за сайтами с разным «внешним видом» могут быть одни и теже люди и если вы серьезно подходите к вопросу выбора ПО, то внешний вид сайтов патнеров — это последнее, на что вы обратите внимание.
Это я к тому, что за сайтами с разным «внешним видом» могут быть одни и теже люди и если вы серьезно подходите к вопросу выбора ПО, то внешний вид сайтов патнеров — это последнее, на что вы обратите внимание.
Есть один хороший пример, касательно надежности — eBay долгое время использовала массивно-паралельную СУБД Greenplum — это не совсем open source, но в основе лежит как раз PostgreSQL. Использовала по крупному — объем данных превышал 6 Петабайт(!). Нареканий на производительность не было. Думаю проблем с поддержкой со стороны Greenplum тоже не было — для такого клиента наверняка постарались. Но eBay был недоволен надежностью Greenplum и поменял ee на очень недешевую Teradata. Чуть подробнее я расписывал тут — bi-review.ru/2010/10/ebay-greenplum-teradata
НЛО прилетело и опубликовало эту надпись здесь
>> И хотя продукты Etersoft и EnterpriseDB не являются бесплатными, они позволяют существенно снизить общую стоимость владения системой за счёт сокращения расходов на лицензионные отчисления.
Для больших баз лицензионные отчисления весьма небольшая часть стоимости владения. SQL Server на один процессор стоит 30 тысяч без скидок. Хороший DBA получает в год с налогами примерно так же.
Для больших баз лицензионные отчисления весьма небольшая часть стоимости владения. SQL Server на один процессор стоит 30 тысяч без скидок. Хороший DBA получает в год с налогами примерно так же.
Копейка рубль бережёт. В бизнесе не бывает «лишних» денег. ;-)
Ну так DBA одни, а процессоров, положим, будет 16. Где ж тут небольшая часть? И это мы сейчас про SQL Server, который ощутимо дешевле Oracle.
P.S. Вы ж уточняйте что речь идет 30 тысяч долларов, а то вдруг кто не поймет.
P.S. Вы ж уточняйте что речь идет 30 тысяч долларов, а то вдруг кто не поймет.
НЛО прилетело и опубликовало эту надпись здесь
Когда я занимался вопросом лицензирования используемого софта (2003 год), то просто обзванивал конторы «партнеров» и спрашивал сколько будет стоить набор, скажем, из 10 XP Pro+ 10 MSO 2003+ 1 Win2k3+ 1 MS SQL + 1 VS 6, причём отдельно отмечал, что мне нужны только бумажки — мне задавали уточняющие вопросы про пользователей, ядра и т. п., через некоторое время перезванивали и говорили «самый дешевый вариант для вас будет такой-то, но с такими-то ограничениями, подороже такой-то, но ограничений практически нет, а если возьмёте не XP и 2k3, а 2k то будет ещё дешевле», но и самый дешевый вариант на начальство производил впечатление "!!!!!1111111"
А Action Pack это для внутреннего использования разработчиками и интеграторами, но не для конечного пользователя, не так ли?
А Action Pack это для внутреннего использования разработчиками и интеграторами, но не для конечного пользователя, не так ли?
какой-то бред вам отвечали, напишите что нужно в личку, я дам вам цены, если что-то интерисует по продукции MS
Я же написал, что это было в 2003 году, уже давно не актуально. В общем, смысл предыдущего коммента в том, что человек не знакомый с тонкостями лицензирования продуктов MS просто обратится к ближайшему партнеру/реселеру MS, чтоб те посчитали (а то и сам посчитает по первому попавшемуся прайсу), устроит цифра — купит, не устроит — не купит, в лучшем случае перейдёт на open-source, в худшем… ну, вы понимаете ;) А вот заинтересованы ли эти партнеры в том, чтобы предложить потенциальному покупателю наиболее выгодный для него комплект лицензий или работают по принципу «лучше раз за год продать на „стопицот милионов“ и весь год кормиться с этой продажи, или брать количеством продаж (чем меньше цены — тем больше количество :) ), я могу только гадать. Но 7 лет назад вопроса „А какой Офис вам нужен, Про или Стандарт (или как там их)?“ я не услышал, приходилось самому уточнять „а какой офис вы посчитали?“ и просить пересчитать, насколько дешевле выйдет
НЛО прилетело и опубликовало эту надпись здесь
Главная причина консерватизма — костность головного мозга. И вообще принципы работы бюрократической машины. Пока сверху не пнут — внизу не пошевелятся. Верхи не знают — низы не могут.
Еще есть один фактор — специалистов по open source СУБД сейчас намного меньше, чем по популярным проприетарным субд. Это, конечно, дело наживное, но нужен некоторый толчок чтобы все сдвинулось с мертвой точки.
На самом деле, ещё один важный фактор — производительность. Где-то года полтора встречал рейтинг, в котором было показано, что Postgres по многим тестам вплотную подбирается к Oracle. Интересно, как на эту статистику повлияет выход Postgres 9.0? Ну и вообще, как повлияет выход девятой ветки на распределение рынка. Конкуренты ведь тоже не дремлют :)
Когда Postgres был ещё 8.0 мелькала даже цифра в 12% разницы производительности.
Хотите я вам так ее померяю, что будет разница 100%? Я пока не видел ни одного сколько-нибудь объективного теста. И, честно сказать, не уверен что объективные тесты вообще возможны при сравнении производительности СУБД.
А вы придумайте критерии объективности? Все системы тестируют одним и тем же образом — на одинаковых конфигурациях запускают набор одинаковых задач и тестируют время выполнения. Чем больше типов задач — тем объективнее тест, вот и всё.
Вот в том то и проблема, что критериев я таких придумать не могу. Но я абсолютно не согласен с утверждением про количество задач. У каждой СУБД есть свои слабые и сильные места, обусловленные, к примеру, архитектурой СУБД. Из-за этого под каждую СУБД разрабатывают приложения по-разному. И именно поэтому не имеет смысла проводить какие-то атомарные тесты, они ничего вам не дадут.
Например, MSSQL — блокировочная субд, а Oracle — мультиверсионник. Это два разных подхода, каждый из которых, обладая своими сильными и слабыми сторонами, влечет за собой разный подход к разработке.
P.S. howfuckedismydatabase.com/
Например, MSSQL — блокировочная субд, а Oracle — мультиверсионник. Это два разных подхода, каждый из которых, обладая своими сильными и слабыми сторонами, влечет за собой разный подход к разработке.
P.S. howfuckedismydatabase.com/
MSSQL мультиверсионник уже как 5 лет.
То, что он поддерживает isolation level snapshot, не делает его мультиверсионником.
А то что он не блочит страницы, больше не делает его блокировочником.
Мультиверсионником его делает честная реализация мультиверсионности.
А почему нельзя попросить специалистов соответствующих компаний продемонстрировать рост производительности именно в том решении, которое вам нужно?
Есть tpc.org — где там Postgree?
Я там выше рассказываю свое мнение о том, что синтетическими тестами измерять производительность бессмысленно,
а вы мне еще пачку результатов таких же тестов подбрасываете. Зачем?
а вы мне еще пачку результатов таких же тестов подбрасываете. Зачем?
Сходил по ссылке, поизучал чуть подробнее. Насколько я понял, сервера с Postgresql там вообще не тестировались. И всего один сервер с mysql. Зато туева гора серверов c mssql, db2 и oracle. И к чему эта ссылка в посте про open source субд?
Брюс Момжан может хоть десять раз повторить однозначно, но сколько не говори «Халва», во рту слаще не станет. Единственным реальным, а не в фантазиях фанатов, свидетельством того, что Postgre уже дозрела до энтерпрайз-задач, будет ее появление в списке того же Forrester.
В ридере сразу за этой статьей выпало Национальное агентство Франции выбрало PostgreSQL в качестве СУБД
Что, как бы, символично…
Что, как бы, символично…
Я клиентам в качестве понятного аргумента всегда говорю, что Skype использует PostgreSQL.
[sarcasm]Ага, а Фейсбук использует MySQL)))[/sarcasm]
Допустим с СУБД все действительно может быть открыто, свободно и т.д. Но ведь нельзя отрицать того, что действительно есть области, которые есть и всегда будут закрытыми и проприетарными. Взять какой-нибудь софт для атомных реакторов, прошивки микроконтроллеров спец.устройств, всякие там программы для луноходов и управляемых боевых человекоподобных роботов. Эти вещи никогда не будут разрабатываться «в открытую». И много еще чего.
Скорее наоборот, там, особенно для ядерных реакторов, софт ВСЕГДА должен быть открытым. Открытость софта, это ведь не открытость всему свету, а открытость для клиента/заказчика.
То явление, что часто, в областях, хотя бы косвенно относящихся к безопасности, софт поставляется без исходников, должно быть уничтожено как класс.
Если что, работал на АЭС и имел отношение к некоторым системам безопасности.
То явление, что часто, в областях, хотя бы косвенно относящихся к безопасности, софт поставляется без исходников, должно быть уничтожено как класс.
Если что, работал на АЭС и имел отношение к некоторым системам безопасности.
Я на АЭС не работал, но очень часто стоял перед выбором: использовать в производстве вот эту закрытую систему за N килобаксов от HP\Siemens\Microsoft\Oracle\Ваш_вариант, зная что у неё куча возможностей, масса плагинов, десятки примеров внедрения, техподдержка, документация и масса совместимых устройств и она точно решит мои задачи или взять вот эти два десятка опенсорсных утилит и попробовать (без всякой гарантии) их соединить воедино.
Когда хотелось чего-то в духе «для души», «интересно же разобраться» и «с перспективой расширения» я выбирал второй путь. Когда было надо «чтобы завтра работало» — первый. И ничего как бы с этим не поделаешь.
Когда хотелось чего-то в духе «для души», «интересно же разобраться» и «с перспективой расширения» я выбирал второй путь. Когда было надо «чтобы завтра работало» — первый. И ничего как бы с этим не поделаешь.
Мой опыт говорит немного по другому. Да, куча документации, да поддержка. Однако никаких гарантий, что «заработает завтра» нет. Скажем закупили мы для разработки одной большой системы примерно 42 комплектов LabView. 2 рабочих места разработчика и 40 рантаймов. И то, что мы разработали на рантаймах не заработало. Пришлось нарушать лицензию. И в техподдержку писали и ничего. Делали бы на открытых решениях. И разработка была бы быстрее и вопросы можно решить, исходники-то есть.
В общем мы сами должны создавать атмосферу, неблагоприятную для закрытых решений. Я имею в виду то, что в идеале все решения, даже от Майкрософт должны быть с исходниками. По крайней мере в промышленности.
В общем мы сами должны создавать атмосферу, неблагоприятную для закрытых решений. Я имею в виду то, что в идеале все решения, даже от Майкрософт должны быть с исходниками. По крайней мере в промышленности.
Странная ситуация когда «купили, а техподдержки нет». Если брать у официального диллера в регионе или использовать компанию-системного интегратора, то техподдержка не то что есть, она есть вплоть до техников и программистов разработчика. Ну, по крайней мере, я в таких проектах участвовал. А если помощи нет и гарантий нет — и вправду лучше искать другие варианты.
Я написал производителю, он переслал дилеру в регион, после двух писаем дилер перестал отвечать. Да и что он мог сделать?
Хочу Вас заверить что это не тех. поддержка корпоративных решений :) В комментарии на который Вы отвечаете речь идет о корпоративных enterprise решениях — в них непосредственно в момент закупки с вендором заключается договор на поддержку и он является одним из важных критериев выбора решения.
Для примера SLA одной из enterprise систем с которой работаю конкретно я:
Для проблем с критичность «Emergency» — 4 часа временное решение (устранение влияния проблемы на основную функциональность системы), 24 часа постоянное решение.
То что Вы описали к enterprise-сегменту не имеет никакого отношения…
Для примера SLA одной из enterprise систем с которой работаю конкретно я:
Для проблем с критичность «Emergency» — 4 часа временное решение (устранение влияния проблемы на основную функциональность системы), 24 часа постоянное решение.
То что Вы описали к enterprise-сегменту не имеет никакого отношения…
… а вы не в курсе, что МС поставляет свои исходники для анализа госструктурами?
В курсе, однако это не решает проблем, ИМХО. В принципе, по моему мнению, какой-то минимальный приемлемый уровень гарантий, обеспечивает наличие исходников и окружения, позволяющего скомпилировать из этих исходников продукт.
В промышленности системы монтируются как правило не меньше, чем на 5-10 лет. А за такой срок уже ни гарантий ни концов не найдешь. Фирмы закрываются, разоряются, покупаются, линейки продуктов закрываются. А возмещение ущерба ИМХО, в пределах стоимости продукта. Вот Вы разработаете систему стоимостью в пару миллионов, базируясь на зарытый продукт, стоимостью в тысячу. И через пять лет у Вас не будет ни гарантий, ни поддержки, ни возможность что-то исправить. Я бывал в таких ситуациях. Никаких концов не найдешь.
Дело не в МС, дело в сложившейся порочной практике непредоставления исходников.
В промышленности системы монтируются как правило не меньше, чем на 5-10 лет. А за такой срок уже ни гарантий ни концов не найдешь. Фирмы закрываются, разоряются, покупаются, линейки продуктов закрываются. А возмещение ущерба ИМХО, в пределах стоимости продукта. Вот Вы разработаете систему стоимостью в пару миллионов, базируясь на зарытый продукт, стоимостью в тысячу. И через пять лет у Вас не будет ни гарантий, ни поддержки, ни возможность что-то исправить. Я бывал в таких ситуациях. Никаких концов не найдешь.
Дело не в МС, дело в сложившейся порочной практике непредоставления исходников.
Я прямо сейчас в такой ситуации, если что.
Именно поэтому предоставление исходников должно быть описано в договоре, и проверяться фактически, а не формально, как у нас это делается в госконтрактах.
Именно поэтому предоставление исходников должно быть описано в договоре, и проверяться фактически, а не формально, как у нас это делается в госконтрактах.
Лет десять назад, когда я работал с большими проектами, продвигал в контрактах эту идею (обязательное предоставление исходников, описание протоколов). Тогда вообще было полное непонимание, что это такое и зачем нужно. Настолько все привыкли, что программный продукт, это только бинарники. Сегодня легче, уже многие понимают, что к чему, оупен сорс на слуху. Но до минимально приемлемого положения еще долбить, долбить и долбить.
Стоп!
Есть вещи, которые не надо путать никогда.
Open-source-продукты — это одно.
Предоставление исходников в рамках контракта — другое.
То, что я передаю исходники при сдаче программного продукта, не делает его Open Source.
Есть вещи, которые не надо путать никогда.
Open-source-продукты — это одно.
Предоставление исходников в рамках контракта — другое.
То, что я передаю исходники при сдаче программного продукта, не делает его Open Source.
Не соглашусь. Я не знаю таких лицензий, которые заставляли бы открывать исходники всему миру. Главное условие GPL, например то, что если Вы кому-то (клиенту) даете ПП, то должны предоставить и исходники. Второе условие, что клиент имеет те же права использования исходников, что и поставщик. Но ни поставщик, ни клиент вовсе не обязан открывать исходники для ВСЕХ. Может, но не обязан.
Это ИМХО, максимально близко, если не то же самое, что и при поставке заказного ПО вместе с исходниками клиенту.
Это ИМХО, максимально близко, если не то же самое, что и при поставке заказного ПО вместе с исходниками клиенту.
Вы не поняли: мой месседж строго обратен.
Если мне, как заказчику, нужен контроль за исходниками, я прописываю это в контракте. И мне сугубо плевать, был ли передаваемый мне продукт open source или же пропьетарной разработкой.
Поэтому не надо думать, что фраза «я хочу иметь полный контроль над исходниками» автоматически означает «мне нужно open source software».
Если мне, как заказчику, нужен контроль за исходниками, я прописываю это в контракте. И мне сугубо плевать, был ли передаваемый мне продукт open source или же пропьетарной разработкой.
Поэтому не надо думать, что фраза «я хочу иметь полный контроль над исходниками» автоматически означает «мне нужно open source software».
Во-первых, Вы в контракте прописываете, что Вам нужен продукт на условиях Open Source.
Во-вторых, если Вы берете продукты Open Source, то исходники получаете автоматически, причем как правило или часто, получаете под открытыми лицензиями все до последнего гвоздя.
В третьих, если вы берете за основу коробочный продукт с закрытыми исходниками, вы хоть разбейтесь в доску, при сегодняшней практике не получите исходников. Или получите, не под той лицензией, которая Вам нужна.
Исходя из этого положение может существенно поправить только более широкое распространение практики Open Source.
А так да, то, что пишете Вы (про контракты) и то, что пишу я не тождественно равно. Но множества, ИМХО сильно пересекаются.
Во-вторых, если Вы берете продукты Open Source, то исходники получаете автоматически, причем как правило или часто, получаете под открытыми лицензиями все до последнего гвоздя.
В третьих, если вы берете за основу коробочный продукт с закрытыми исходниками, вы хоть разбейтесь в доску, при сегодняшней практике не получите исходников. Или получите, не под той лицензией, которая Вам нужна.
Исходя из этого положение может существенно поправить только более широкое распространение практики Open Source.
А так да, то, что пишете Вы (про контракты) и то, что пишу я не тождественно равно. Но множества, ИМХО сильно пересекаются.
«Во-первых, Вы в контракте прописываете, что Вам нужен продукт на условиях Open Source.»
Нет, этого я в контракте не пишу. Мне это не нужно.
«В третьих, если вы берете за основу коробочный продукт с закрытыми исходниками, вы хоть разбейтесь в доску, при сегодняшней практике не получите исходников. Или получите, не под той лицензией, которая Вам нужна.»
Почему же? Все зависит исключительно от заплаченных денег.
Нет, этого я в контракте не пишу. Мне это не нужно.
«В третьих, если вы берете за основу коробочный продукт с закрытыми исходниками, вы хоть разбейтесь в доску, при сегодняшней практике не получите исходников. Или получите, не под той лицензией, которая Вам нужна.»
Почему же? Все зависит исключительно от заплаченных денег.
> Нет, этого я в контракте не пишу. Мне это не нужно.
Вероятно, я неясно выразился, Вы в контракте прописываете условия, которые близки к условиям Open Source.
Вероятно, я неясно выразился, Вы в контракте прописываете условия, которые близки к условиям Open Source.
Извините, но вы не правы. Условия, о которых я говорю, похожи на open source только словом source. Вы не читали определение (http://en.wikipedia.org/wiki/Open_Source_Definition)?
Извините, сорвалось.
Типовой контракт не включает ни права на распространение, а это первый и основной пункт OSD.
Типовой контракт не включает ни права на распространение, а это первый и основной пункт OSD.
— Как я понимаю, то, что Вы имеете в виду, не все условия Ваших контрактов совпадают с условиями Open Source Definition. Однако же во многом совпадают. С другой стороны, встречаются лицензии, которые не подходят под условия Open Source Definition, например BSD, но их тоже можно считать открытыми. Open Source Definition — это не более, чем один из взглядов/инициатив.
— Что такое типовой контракт? Контракт это договор между сторонами, может быть любым, не противоречащим законодательству.
— Иногда не нужно право на распространение, а иногда нужно. Иногда и более хитрые ситуации встречаются. Это собственно предмет переговоров.
— Что такое типовой контракт? Контракт это договор между сторонами, может быть любым, не противоречащим законодательству.
— Иногда не нужно право на распространение, а иногда нужно. Иногда и более хитрые ситуации встречаются. Это собственно предмет переговоров.
Типовой контракт — это тот, который мне чаще всего встречался в практике.
Чаще всего когда мы говорим о ситуации «я не хочу, чтобы моя система зависела от чужого закрытого кода», мы покупаем этот код и право на его использование в рамках своей системы. Прако на его дальнейшее распространение в виде кода, право на продажу системы отдельно — нам не нужны, а, значит, экономически не оправданы (учитывая то, сколько за это захочет разработчик).
Чаще всего когда мы говорим о ситуации «я не хочу, чтобы моя система зависела от чужого закрытого кода», мы покупаем этот код и право на его использование в рамках своей системы. Прако на его дальнейшее распространение в виде кода, право на продажу системы отдельно — нам не нужны, а, значит, экономически не оправданы (учитывая то, сколько за это захочет разработчик).
Особенно для ядерных реакторов, да: habrahabr.ru/blogs/infosecurity/108464/
Если же без крайностей, то софт для спецприменений практически всегда делается из имеющегося _открытого_ софта. Потому что это единственный способ гарантировать чистоту исходников.
Если же без крайностей, то софт для спецприменений практически всегда делается из имеющегося _открытого_ софта. Потому что это единственный способ гарантировать чистоту исходников.
К сожалению в некоторых областях в промышленности, де-факто стандартами в промышленности стали решения на основе Windows, выбор софта на открытых решениях очень слабый. Это различные SCADA системы и OPC сервера.
Приходится кушать кактус.
Приходится кушать кактус.
Есть нюансы. К сожалению стандартами де-факто в промышленных применениях стали закрытые решения на базе Windows (OPC-сервера, системы SCADA).
Так что многим разработчикам хочешь не хочешь приходится кушать кактус. Я имею в виду закрытые решения.
Так что многим разработчикам хочешь не хочешь приходится кушать кактус. Я имею в виду закрытые решения.
Софт для «спецприменений» как правило пишется с нуля. На то оно и спецприменение, что аналогов нет. Можно рассуждать о выбираемых для этого софта ОС, БД и т.д., но основной код уникален и часто является предметом авторского права и патентов. Куда уж его раскрывать.
Ну и кто мне может дать какие-то гарантии лет на 10? А это еще небольшой срок для серьезной системы.
При закрытых исходниках получаешь на руки бинарники, которые в любой момент могут отказать, например лет через 5-7. И фирмы изготовителя к этому времени уже может не быть в списке живых.
В 2000 году я был ровно в такой ситуации. Пришлось делать весьма уродский воркэраунд.
При закрытых исходниках получаешь на руки бинарники, которые в любой момент могут отказать, например лет через 5-7. И фирмы изготовителя к этому времени уже может не быть в списке живых.
В 2000 году я был ровно в такой ситуации. Пришлось делать весьма уродский воркэраунд.
Разумеется, финальный код специфичен и не раскрывается. Но никто не будет писать операционную систему с нуля (ну, почти никто:)). Берётся версия линукса, просмотренная специалистами на отсутствие закладок, и из неё лепится то что нужно.
Ну, зависит от ситуации, конечно — есть «спецсофт» и на винде.
Ну, зависит от ситуации, конечно — есть «спецсофт» и на винде.
НЛО прилетело и опубликовало эту надпись здесь
Да, MyTaskHelper.ru
Те решения, что я видео на Оракле, нормально будут работать и на SQLite, но на Оракле можно больше отмыть на «интеграции» и «тендерных» закупках оборудования.
У самого куча проектов уровня ERP, всё живёт на Firebird, плюс один новый ради интереса решили сгородить на PostgreSQL. Таблицы измеряются сотнями миллионов записей и гигабайтными объёмами, но что-то пока не видно узких мест, в которые в ближайшие годы возможно будет упереться.
Думаю что в СНГ 90% систем на проприетарных монструозных СУБД городится по двум причинам:
— Желание заработать (украсть) на интеграции
— Отсутствие базовых знаний реляционной алгебры и методов оптимизации структур и запросов. О грамотной архитектуре приложений вообще речи не идёт.
У самого куча проектов уровня ERP, всё живёт на Firebird, плюс один новый ради интереса решили сгородить на PostgreSQL. Таблицы измеряются сотнями миллионов записей и гигабайтными объёмами, но что-то пока не видно узких мест, в которые в ближайшие годы возможно будет упереться.
Думаю что в СНГ 90% систем на проприетарных монструозных СУБД городится по двум причинам:
— Желание заработать (украсть) на интеграции
— Отсутствие базовых знаний реляционной алгебры и методов оптимизации структур и запросов. О грамотной архитектуре приложений вообще речи не идёт.
>Думаю что в СНГ 90% систем на проприетарных монструозных СУБД городится по двум причинам:
>— Отсутствие базовых знаний реляционной алгебры и методов оптимизации структур и запросов. О грамотной архитектуре приложений вообще речи не идёт.
Как-то не пойму как из отсутствия знаний реляционной алгебры вытекает использование проприетарных монстров? SQL — он и в Африке SQL, либо ты понимаешь как работают запросы и какие под них лучше создавать структуры, либо не понимаешь, а какой движок их будет выполнять дело десятое, если не знаешь особенностей ни одного. Другое дело, если есть базовые знания одного движка/диалекта и тебе нужно принять решение какой использовать, то, вероятней всего, будешь использовать знакомый. Но будет это проприетарный или открытый — случайность, имхо.
>— Отсутствие базовых знаний реляционной алгебры и методов оптимизации структур и запросов. О грамотной архитектуре приложений вообще речи не идёт.
Как-то не пойму как из отсутствия знаний реляционной алгебры вытекает использование проприетарных монстров? SQL — он и в Африке SQL, либо ты понимаешь как работают запросы и какие под них лучше создавать структуры, либо не понимаешь, а какой движок их будет выполнять дело десятое, если не знаешь особенностей ни одного. Другое дело, если есть базовые знания одного движка/диалекта и тебе нужно принять решение какой использовать, то, вероятней всего, будешь использовать знакомый. Но будет это проприетарный или открытый — случайность, имхо.
Во-первых: огромное количество систем, разрабатываемых под Оракл и MS SQL не используют те самые «супер фичи» данных СУБД, ради которых и платят за них немалые деньги.
Во-вторых: городят офигенно неоптимизированные структуры и обращаются к ним офигенно кривыми запросами. На более простых СУБД естесственно это не проходит и потому покупаются дорогие СУБД с большим здоровьем и мощными планировщиками запросов.
А потом под эти СУБД покупается ещё более дорогое железо, дабы всё построенное хоть как-нибудь бы ворочалось.
Во-вторых: городят офигенно неоптимизированные структуры и обращаются к ним офигенно кривыми запросами. На более простых СУБД естесственно это не проходит и потому покупаются дорогие СУБД с большим здоровьем и мощными планировщиками запросов.
А потом под эти СУБД покупается ещё более дорогое железо, дабы всё построенное хоть как-нибудь бы ворочалось.
Ну так это не супер большой размер все же. Хотелось бы примеров с базами, скажем, хотя бы 5-10 терабайт (без медиаконтента и прочих блобов), а число-строковых данных.
Да взять тот же самый skype.
5-10Тб не видел на FB, но 1Тб ради теста гоняли, а реально рабочую на 300Гб видел. Тест 1Тб показал что нет заметной деградации скорости обработки запросов в зависимости от объёма базы. Если говорить простым языком, то при условии что здоровья у сервака хватает, то индексированный запрос 100 записей из таблицы, содержащей 1млн записей и из таблицы, содержащей 1мрд записей, по скорости отличается незначительно.
В FB 2.5 анонсированы запросы из одной базы к другой. За счёт подобного функционала можно делать прозрачное партицирование на несколько серверов. А за счёт давно существующего механизма двухфазных транзакций можно строить репликацию Master-MultiSlave без существенных доработок софта.
В FB 2.5 анонсированы запросы из одной базы к другой. За счёт подобного функционала можно делать прозрачное партицирование на несколько серверов. А за счёт давно существующего механизма двухфазных транзакций можно строить репликацию Master-MultiSlave без существенных доработок софта.
Если Postrgess так удобен, быстр и масштабируем. то где он на сайте tpc.org/tpcc/results/tpcc_perf_results.asp
(да, я понимаю что tpc это синтетические тесты, все же)
Если бы там было упоминание Postgress — мне было проще общаться с руководством по выбору это СУБД…
(да, я понимаю что tpc это синтетические тесты, все же)
Если бы там было упоминание Postgress — мне было проще общаться с руководством по выбору это СУБД…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Есть ли альтернатива гигантам рынка СУБД?