Нет, вот на эту тему ораклоиды точно говорить не любят. Но вангую, что к их собственной конференции MySQL Connect в сентябре у них наверняка запланирован какой-то важный milestone. Это может быть бета релиз, а может и финальный.
А теперь представьте, что спустя три года, т.е. в 2019 году я на Хабре начну критиковать PostgreSQL за этот самый баг. Представили? Вот, примерно такими дураками вы выглядите, когда пытаетесь критиковать MySQL.
Спасибо. Краткое резюме для того, чтобы у меня и других была полная картина происшествия:
проблема выражается в неверных возвращаемых данных с определёнными локалями на определённых распространённых версиях дистрибутивов, в которых есть ошибка в strxfrm() в glibc;
проблема появилась в ветке 9.5, первый стабильный релиз которой вышел 7 января 2016г.;
проблема была обнаружена только 21 марта 2016г.;
исправление было внесено в исходный текст 23 марта;
исправление заключается в запрете оптимизации abbreviated keys для всех не-C локалей
исправление будет выпущено 31 марта
тем, кто не может ждать 31 марта, рекомендуется пересобрать и обновить PostgreSQL самостоятельно, либо сменить дистрибутив, либо отказаться от использования не-C локалей.
Кстати, мне в связи с этим багом стало любопытно, кто и как занимается QA для Postgres. В смысле, есть ли выделенная компания, команда, человек, которые занимаются исключительно тестированием, составлением регрессионных тестов, проверкой покрытия, и т.д.? Я не говорю, что все это плохо делается, но определённые вопросы этот баг поднимает. Можете ответить? Спасибо.
С точки зрения пользователя, естественно это проблема в PostgreSQL. Рад, что исправление было закоммичено через 2 дня. Что я, как пользователь, должен сделать, чтобы получить исправленную версию?
Обновил раздел о соответствии стандартам. Оказывается, бывают случаи, где MySQL лучше поддерживает стандарт SQL, чем PostgreSQL. Теперь есть ссылка на соответствующую статью.
А по поводу миграций, те люди, которые могут рассказать о каких-то реальных историях с клиентами, в том числе и о миграциях, связаны всякими договорами о неразглашениях. Сами же клиенты, по крайней мере большие компании, по разным причинам тоже стараются не разглашать такие вещи. Я вот сам такую историю недавно услышал про Яндекс. Но не хочу пересказывать, чтобы никого не подводить.
Редкие исключения бывают. Вот например Uber рассказывает о внедрении MySQL параллельно к существующей инфраструктуре на PostgreSQL. Это не совсем «миграция», но тоже показательная вещь
Оракл заинтересован, чтобы MySQL оставался СУБД #1 для web. В такой позиции есть как минусы (в других нишах он не заинтересован), так и плюсы (эту нишу он просто так не отдаст, и будет вкладывать туда столько ресурсов, сколько нужно для сохранения статус-кво).
Я человека никак не обзывал, а долго, доброжелательно и терпеливо объяснял однобокость его взглядов на мир. А вот вы типичный представитель той самой религиозной секты. Цитаты с хамством в отношении меня привести?
Главное препятствие, имхо, для PostgreSQL — это его некая элитарность в плане администрирования, а не модели разработки и копирайты.
У меня в планах ещё две статьи, где в том числе и эту тему буду разбирать. И возможно ещё одна, заключительная, с подведением неутешительных итогов культурного обмена. Пока слишком занят.
О, боевая пехота подтянулась. То есть, когда вот вы лично хамили мне, а я старался избегать любой критики PostgreSQL, всё было нормально. Когда я начал критиковать PostgreSQL, естественно начались вопли «а нас-то за что? Хамство!»
Вы где пропадали-то всё это время? На мои вопросы в посте про репликацию не желаете ответить? Ни единого уточнения, и ни единого ответа от сообщества PostgreSQL пока не последовало.
Я пытаюсь объяснить очевидную вещь: принадлежность разработки сообществу определяется желанием разработчиков слушать это самое сообщество. А не наличием/отсутствием копирайта, лицензией, тесткейсами и прочим.
У меня лично есть много претензий к взаимодействию Oracle с сообществом. Это потому, что я взаимодействовал с Oracle не раз в качестве этого самого «сообщества». Но я вижу огромные изменения к лучшему за последние пару лет. А вот вы лично что знаете на эту тему, чтобы делать выводы космического масштаба и космической же глупости?
MariaDB вы упорно приводите в пример образцового open source проекта. А про MariaDB Enterprise вы ничего не слышали? Или вот почему сравнивать нужно обязательно PostgreSQL с MySQL. А кто выбирает, что с чем можно и нужно сравнивать? А вот если мы сравним MariaDB с EnterpriseDB? Где разработка будет более открытой? И где можно посмотреть список уязвимостей EnterpriseDB? А нужно ли объяснять, почему его нигде нет?
По поводу багтрекера, вот что мне говорили на этот счёт люди из PostgreSQL сообщества (те, которые без религиозных заморочек): «да, разработкой управляют старпёры, которым очень трудно объяснить необходимость багтрекера». И я рад, что понимание есть. Багтрекера вот только нет, правильно?
И да, сотрудников вашей компании и сообщество PostgreSQL в целом я не раз замечал в совершенно необоснованных утверждениях при очень слабом представлении о предмете. Упорство в отстаивании этих утверждений мне напоминает религиозную секту. Одна из целей этих статей — вернуть вас к реальности.
Но я не желаю вашей компании ничего плохого. Я даже пошутил, когда говорил, что долго вы не проживёте. Проживёте конечно, просто повзрослеете. Когда-нибудь сладкий дурман инвесторских денег рассеется и выяснится, что разработка софта и чтение лекций в университетах — это очень романтично, но денег не приносит. И умные люди посоветуют, что для построения устойчивой бизнес-модели нужны подписки, а не одноразовые договоры. А дальше выяснится, что для удержания клиентов в рамках подписки нужно добавлять какие-то уникальные предложения, которых больше ни у кого нет. Единственное, что в open source бизнесе можно придумать — это проприетарные расширения или форки. А потом придут другие люди с большими деньгами и серьёным промышленным применением PostgreSQL, которые попросят не публиковать уязвимости. И ваш гордый ответ «А у нас, знаете ли, всё принадлежит сообществу!» им не понравится. И придётся вылезти из детских штанишек, перестать кричать «MySQL — проприетарщина!» и всё у вас будет хо-ро-шо.
1. В MySQL есть один проприетарный форк, а в PostgreSQL много. При этом PostgreSQL «открытый», а MySQL «проприетарщина».
2. В MySQL есть закрытые баги в багтрекере. А в PostgreSQL багтрекера нет совсем. Поэтому PostgreSQL «открытый», а MySQL «проприетарный»
3. В PostgreSQL все решения принимает сравнительно небольшая группа людей. Вот решили, что не нужен им багтрекер, и нет его. Решили, что не будет встроенной логической репликации, и нет её. Решили, что не нужны хинты в оптимайзере, и нет их. Но конечно же, «процесс разработки открыт и принадлежит сообществу». Эти мантры сколько не повторяй, реальностью они не станут.
А коммерческая компания не только имеет эксклюзивные права на продукт, но и вкладывает в разработку эксклюзивные коммерческие средства. Которые позволяют MySQL оставаться лидирующей базой данных для веб без каких-либо шансов для PostgreSQL занять эту нишу в обозримом будущем. Никаких сравнимых средств в разработку PostgreSQL никто вкладывать не станет, потому что лицензия BSD к этому не располагает, так как все результаты инвестиций окажутся в чьём-то проприетарном форке.
Парни, вы там в Postgres Professional молодцы со всех сторон, но с таким однобоким восприятием реальности я боюсь, что вы долго не проживёте. Религиозные секты долго не живут.
Я до сих пор не очень понял отличие между EnterpriseDB и MySQL Enterprise в контексте разговоров о проприетарности MySQL. Но по просьбам включаю абзац из предыдущего комментария в статью.
1. Правильно ли я понимаю, что на текущий момент только Oracle имеет право создавать закрытые коммерческие форки MySQL, такие как MySQL Enterprise?
Да, лицензия GPL, под которой распространяется MySQL не допускает смену лицензии, в том числе на проприетарную. Поэтому закрытых форков нет. Oracle, как владелец копирайта, лицензию может менять по своему усмотрению.
BSD лицензия, под которой распространяется PostgreSQL, допускает смену лицензии. Поэтому много проприетарных форков.
2. Что стало с темой, которая вызвала брожение умов в 2012 году? Ведь именно с этого момента и пошло «MySQL – проприетарщина».
Думаю, «MySQL — проприетарщина» пошло гораздо раньше, с 2007-го года , когда появился MySQL Enterprise.
Тем не менее, по поводу закрытых багов и закрытых тесткейсов, поясняю: любая уязвимость с точки зрения безопасности, видна только сообщившему и Oracle, но не всем желающим. Oracle включает в уязвимости любой баг, приводящий к падению сервера в неотладочной сборке сервера. Соответствующие регрессионные тесты тоже скрываются, потому что это сделало бы остальные ограничения бессмысленными. Исправления же (т.е. сам код) естественно всегда доступны всем. Это политика Oracle, схожую политику применяет Redhat. Здесь они подробно объясняют причины. Redhat Linux проприетарщиной тоже никто не называет.
Всё верно?
Редкие исключения бывают. Вот например Uber рассказывает о внедрении MySQL параллельно к существующей инфраструктуре на PostgreSQL. Это не совсем «миграция», но тоже показательная вещь
У меня в планах ещё две статьи, где в том числе и эту тему буду разбирать. И возможно ещё одна, заключительная, с подведением неутешительных итогов культурного обмена. Пока слишком занят.
Вы где пропадали-то всё это время? На мои вопросы в посте про репликацию не желаете ответить? Ни единого уточнения, и ни единого ответа от сообщества PostgreSQL пока не последовало.
У меня лично есть много претензий к взаимодействию Oracle с сообществом. Это потому, что я взаимодействовал с Oracle не раз в качестве этого самого «сообщества». Но я вижу огромные изменения к лучшему за последние пару лет. А вот вы лично что знаете на эту тему, чтобы делать выводы космического масштаба и космической же глупости?
MariaDB вы упорно приводите в пример образцового open source проекта. А про MariaDB Enterprise вы ничего не слышали? Или вот почему сравнивать нужно обязательно PostgreSQL с MySQL. А кто выбирает, что с чем можно и нужно сравнивать? А вот если мы сравним MariaDB с EnterpriseDB? Где разработка будет более открытой? И где можно посмотреть список уязвимостей EnterpriseDB? А нужно ли объяснять, почему его нигде нет?
По поводу багтрекера, вот что мне говорили на этот счёт люди из PostgreSQL сообщества (те, которые без религиозных заморочек): «да, разработкой управляют старпёры, которым очень трудно объяснить необходимость багтрекера». И я рад, что понимание есть. Багтрекера вот только нет, правильно?
И да, сотрудников вашей компании и сообщество PostgreSQL в целом я не раз замечал в совершенно необоснованных утверждениях при очень слабом представлении о предмете. Упорство в отстаивании этих утверждений мне напоминает религиозную секту. Одна из целей этих статей — вернуть вас к реальности.
Но я не желаю вашей компании ничего плохого. Я даже пошутил, когда говорил, что долго вы не проживёте. Проживёте конечно, просто повзрослеете. Когда-нибудь сладкий дурман инвесторских денег рассеется и выяснится, что разработка софта и чтение лекций в университетах — это очень романтично, но денег не приносит. И умные люди посоветуют, что для построения устойчивой бизнес-модели нужны подписки, а не одноразовые договоры. А дальше выяснится, что для удержания клиентов в рамках подписки нужно добавлять какие-то уникальные предложения, которых больше ни у кого нет. Единственное, что в open source бизнесе можно придумать — это проприетарные расширения или форки. А потом придут другие люди с большими деньгами и серьёным промышленным применением PostgreSQL, которые попросят не публиковать уязвимости. И ваш гордый ответ «А у нас, знаете ли, всё принадлежит сообществу!» им не понравится. И придётся вылезти из детских штанишек, перестать кричать «MySQL — проприетарщина!» и всё у вас будет хо-ро-шо.
1. В MySQL есть один проприетарный форк, а в PostgreSQL много. При этом PostgreSQL «открытый», а MySQL «проприетарщина».
2. В MySQL есть закрытые баги в багтрекере. А в PostgreSQL багтрекера нет совсем. Поэтому PostgreSQL «открытый», а MySQL «проприетарный»
3. В PostgreSQL все решения принимает сравнительно небольшая группа людей. Вот решили, что не нужен им багтрекер, и нет его. Решили, что не будет встроенной логической репликации, и нет её. Решили, что не нужны хинты в оптимайзере, и нет их. Но конечно же, «процесс разработки открыт и принадлежит сообществу». Эти мантры сколько не повторяй, реальностью они не станут.
А коммерческая компания не только имеет эксклюзивные права на продукт, но и вкладывает в разработку эксклюзивные коммерческие средства. Которые позволяют MySQL оставаться лидирующей базой данных для веб без каких-либо шансов для PostgreSQL занять эту нишу в обозримом будущем. Никаких сравнимых средств в разработку PostgreSQL никто вкладывать не станет, потому что лицензия BSD к этому не располагает, так как все результаты инвестиций окажутся в чьём-то проприетарном форке.
Парни, вы там в Postgres Professional молодцы со всех сторон, но с таким однобоким восприятием реальности я боюсь, что вы долго не проживёте. Религиозные секты долго не живут.
Да, лицензия GPL, под которой распространяется MySQL не допускает смену лицензии, в том числе на проприетарную. Поэтому закрытых форков нет. Oracle, как владелец копирайта, лицензию может менять по своему усмотрению.
BSD лицензия, под которой распространяется PostgreSQL, допускает смену лицензии. Поэтому много проприетарных форков.
Думаю, «MySQL — проприетарщина» пошло гораздо раньше, с 2007-го года , когда появился MySQL Enterprise.
Тем не менее, по поводу закрытых багов и закрытых тесткейсов, поясняю: любая уязвимость с точки зрения безопасности, видна только сообщившему и Oracle, но не всем желающим. Oracle включает в уязвимости любой баг, приводящий к падению сервера в неотладочной сборке сервера. Соответствующие регрессионные тесты тоже скрываются, потому что это сделало бы остальные ограничения бессмысленными. Исправления же (т.е. сам код) естественно всегда доступны всем. Это политика Oracle, схожую политику применяет Redhat. Здесь они подробно объясняют причины. Redhat Linux проприетарщиной тоже никто не называет.
Это в достаточной степени раскрывает тему?